A bit of programming for a change, though not at my normal programming desktop, because I wanted to be next to the meter as I did the testing. Anyone who wants to complain about the fact that I bought a "cheap sh*t meter", send me a better one and I'll use it if it covers my requirements (including having the data protocol documented). Meter has a single use environment (board repair) where the cheapness is not an issue. Aside from this one quirk everything else is covered well (diode mode, resistance, volts and frequency) at a cost that was hard to pass up; difficult to justify spending 5x the price for no real use gains.
That's the idea, yes. I've got my "higher spec" hand held meters for when I need precision work; for board repair it's a low demand criterion and this did a good job fitting the need. I bought the Protek 806 many years ago, with calibration, back for when I was doing micro power circuit design and needed 0.1uA resolution; it however wasn't really a good meter for board repairs.
Thanks for showing this. You're doing this and I'm sitting here with a bunch of post it notes with variable names and "true" or "false" on either side. I'm flipping them over as I read through my code trying to debug a state machine.
oh that can drive you insane when you get through so far and still manage to mis-flip things. I know people love debuggers for a lot of stuff but often doing it like you are is the best way. Good luck with the state machine.
The problem of key reception is that you need a delay before the first command is sent. When you manually change the range your software immediately sends the change range command, while the meter is in a debounce timeout from the manual key. After you detect the wrong mode, delay for an initial debounce period, then send the first mode change, debounce delay, send second mode change.
At least this software is a different variant to the one he's using, same core engine though but this at least is going to be specific for my use here. I do find it so useful being able to code up software to my requirements. Getting Louis to update software is quite a process.
that's kinda neat. didn't even know could reprogram those kinda things.. specially the cheap crappy ones that mentioned in the pinned comment. i guess there's always away to do something to stuff i guess with enough force or know how or it has a thing for it lmao.
In this case, I'm not reprogramming the meter itself but rather I'm using the software I wrote for displaying/collecting the data through the serial interface to act as a manager for the meter, to look out for the condition that annoys me and apply the fix required. If I don't run the software on the PC with the data link the meter will behave as per normal with the quirk that I dislike.
Not that I can find; would be nice if there was. I suppose I could try cycle through a range of byte codes... and hope I don't cause a mess to the calibrations
@@robc8468 would likely just be as much drama remembering to turn it on/off. I've come to get used to it, especially since now the software I've written forces it out of auto-range mode when volts are selected.
Don't delay, program with paul daniels today! is the VC8145 firmware locked? ie can't update it at all? just wondering cause if user can't do a firm upgrade that could be a bugger if a firmware flaw was found and the user was sol being unable to upgrade.
Looks like the HT48R30 they include is actually able to be reprogrammed, but not sure if anyone has a sane tool to do it other than from Holtek themselves. In some ways, it almost might be easier to produce an daughterboard with a different MCU (ATMega likely would suffice with a lot of performance/capacity to spare). Likely just not worth it, easier to simply work around the behaviour as I've done or get a different meter.
by the looks of it, I think it was more to do with potentially causing undefined behaviour due to not reading back the response from the meter after I sent the range-change request. If you check the code where I do the send_cmd() -> byte_read() -> send_cmd() -> byte_read() sequence to shift in to the new state, you'll see there's no delays there, it's as fast as the meter will receive reply. @15:44 you can see I've highlighted the two 0xA1 bytes which were in the meter output buffer waiting to be picked up because at that stage in the coding, I wasn't listening for the reply back. By the time I get to about @19:56 I've put in the new function to retrieve the response byte and from there it works perfectly.
A bit of programming for a change, though not at my normal programming desktop, because I wanted to be next to the meter as I did the testing.
Anyone who wants to complain about the fact that I bought a "cheap sh*t meter", send me a better one and I'll use it if it covers my requirements (including having the data protocol documented).
Meter has a single use environment (board repair) where the cheapness is not an issue. Aside from this one quirk everything else is covered well (diode mode, resistance, volts and frequency) at a cost that was hard to pass up; difficult to justify spending 5x the price for no real use gains.
That's the idea, yes. I've got my "higher spec" hand held meters for when I need precision work; for board repair it's a low demand criterion and this did a good job fitting the need.
I bought the Protek 806 many years ago, with calibration, back for when I was doing micro power circuit design and needed 0.1uA resolution; it however wasn't really a good meter for board repairs.
What may work for you may not work for others, but ..... who cares for others 😁
Great job to see how you can reprogram to fit your requirements
If you are happy with it and it does what you want it to do - win - win. Regards, Dave
Too right.
Thanks for showing this. You're doing this and I'm sitting here with a bunch of post it notes with variable names and "true" or "false" on either side. I'm flipping them over as I read through my code trying to debug a state machine.
oh that can drive you insane when you get through so far and still manage to mis-flip things. I know people love debuggers for a lot of stuff but often doing it like you are is the best way. Good luck with the state machine.
The problem of key reception is that you need a delay before the first command is sent. When you manually change the range your software immediately sends the change range command, while the meter is in a debounce timeout from the manual key. After you detect the wrong mode, delay for an initial debounce period, then send the first mode change, debounce delay, send second mode change.
Man you should do more coding videos, really inspirational work there!
As soon as you fix this, Louis will complain about something else.
Wait, who am I kidding? Louis never updates his software.
At least this software is a different variant to the one he's using, same core engine though but this at least is going to be specific for my use here. I do find it so useful being able to code up software to my requirements.
Getting Louis to update software is quite a process.
Writing C with vi; take me back to 1979.
Awesome coding 👍 Lot more faster response Looks like you get out of the meter 😃
that's kinda neat. didn't even know could reprogram those kinda things.. specially the cheap crappy ones that mentioned in the pinned comment. i guess there's always away to do something to stuff i guess with enough force or know how or it has a thing for it lmao.
In this case, I'm not reprogramming the meter itself but rather I'm using the software I wrote for displaying/collecting the data through the serial interface to act as a manager for the meter, to look out for the condition that annoys me and apply the fix required.
If I don't run the software on the PC with the data link the meter will behave as per normal with the quirk that I dislike.
oh i see now. so just a passive fix rather a permanent one. well that sucks but i guess its something for now aha.
Is there a command to turn off the beeper? Might be an option
Not that I can find; would be nice if there was. I suppose I could try cycle through a range of byte codes... and hope I don't cause a mess to the calibrations
@@pldaniels why not unsolder the beeper and put an on off switch in series with the beeper?
@@robc8468 would likely just be as much drama remembering to turn it on/off. I've come to get used to it, especially since now the software I've written forces it out of auto-range mode when volts are selected.
Don't delay, program with paul daniels today!
is the VC8145 firmware locked? ie can't update it at all? just wondering cause if user can't do a firm upgrade that could be a bugger if a firmware flaw was found and the user was sol being unable to upgrade.
Looks like the HT48R30 they include is actually able to be reprogrammed, but not sure if anyone has a sane tool to do it other than from Holtek themselves. In some ways, it almost might be easier to produce an daughterboard with a different MCU (ATMega likely would suffice with a lot of performance/capacity to spare). Likely just not worth it, easier to simply work around the behaviour as I've done or get a different meter.
@25:00 the unreliability is probably due to collisions in the serial communications.
by the looks of it, I think it was more to do with potentially causing undefined behaviour due to not reading back the response from the meter after I sent the range-change request.
If you check the code where I do the send_cmd() -> byte_read() -> send_cmd() -> byte_read() sequence to shift in to the new state, you'll see there's no delays there, it's as fast as the meter will receive reply.
@15:44 you can see I've highlighted the two 0xA1 bytes which were in the meter output buffer waiting to be picked up because at that stage in the coding, I wasn't listening for the reply back. By the time I get to about @19:56 I've put in the new function to retrieve the response byte and from there it works perfectly.
Hi Paul, if you make yourself a member of the dialout group you don't have to launch your program with sudo...
Thanks, I forget that I can do that. Laziness.
You're more than welcome :)
Good for ya! Glad your happy with it! could you find some firmware to upgrade my noggan? Ha ha good vid again Paul!
Would be nice to get some firmware upgrades for the head... and body :D
Paul Daniels If you do come to Canada, make sure to let me know !
I SUBBED TO PAUL DANIELS