The LinkMeter Snapshot and YOU
- Thread starter Bryan Mayland
- Start date
Thx, did that again now but noticed an error:
Connecting to capnbry.net (71.100.233.140:80)
hm.hex 65% |******************** | 47310 0:00:00 ETA
hm.hex 100% |*******************************| 67722 0:00:00 ETA
Stopping LinkMeter OK
LinkMeter platform is BCM2708
AVR fuses ERROR
Starting LinkMeter
Any idea?
Bryan Mayland
TVWBB Hall of Fame
EDIT: Ah that's why it didn't get the latest firmware. You've got a problem somewhere in the SPI communication between your HeaterMeter and the Pi. Check these connections with a multimeter for continuity:
Last edited:
RalphTrimble
TVWBB Diamond Member
It's always worth a try to reseat the rPi, the SD Card and the ATMega chip in its socket... Only takes a second and I have seen it remedy strange issues.
Bryan Mayland
TVWBB Hall of Fame
I don't know! Clearly it worked one time, enough to flash the first image. You try maybe slowing down the bitrate (which is what it does on the first upload because the default clock is very slow). SSH in and type this
The first two might say "file exists" but that is ok.
Code:
insmod spidev
insmod spi-bcm2708
hmdude -v -v -b 128 -P/dev/spidev0.0 -U/lib/firmware/hm.hexThe first two might say "file exists" but that is ok.
RalphTrimble
TVWBB Diamond Member
I was gonna ask if this was the exact same hardware that was in place when this ATMega was flashed the first time?.....
root@heatermeter:~# hmdude -v -v -b 128 -P/dev/spidev0.0 -U/lib/firmware/hm.hex
hmdude: compiled on Sep 8 2015 at 10:00:37
Using port: /dev/spidev0.0
Loading ihex file: "/lib/firmware/hm.hex" (24072 bytes)
SPI speed: 128 KHz
Can't set AVR programming mode (0x00)
Hardware didn't change since first install...
I also found something in another thread, to run hmdude -b 128 -P/dev/spidev0.0
root@heatermeter:~# cat /dev/ttyAMA0
$HMSU,80,U,283.6,U,U,0,0,0*4F
$HMSU,80,U,283.6,U,U,0,0,0*4F
$HMAR,0,1,0,0,0,1*16
$HMSU,80,U,283.3,U,U,0,0,0*4A
$HMSU,80,U,283.3,U,U,0,0,0*4A
$HMSU,80,U,282.9,U,U,0,0,0*41
$HMSU,80,U,282.9,U,U,0,0,0*41
$HMAR,0,1,0,0,0,1*16
$HMSU,80,U,282.9,U,U,0,0,0*41
$HMSU,80,U,282.6,U,U,0,0,0*4E
$HMSU,80,U,282.6,U,U,0,0,0*4E
$HMSU,80,U,282.3,U,U,0,0,0*4B
$HMAR,0,1,0,0,0,1*16
$HMSU,80,U,282.3,U,U,0,0,0*4B
$HMSU,80,U,282.0,U,U,0,0,0*48
$HMSU,80,U,281.9,U,U,0,0,0*42
$HMSU,80,U,281.9,U,U,0,0,0*42
$HMAR,0,1,0,0,1,1*17
$HMSU,80,U,281.6,U,U,0,0,0*4D
$HMSU,80,U,281.6,U,U,0,0,0*4D
$HMSU,80,U,281.3,U,U,0,0,0*48
$HMSU,80,U,281.3,U,U,0,0,0*48
$HMAR,0,1,0,0,0,1*16
$HMSU,80,U,281.1,U,U,0,0,0*4A
$HMSU,80,U,281.0,U,U,0,0,0*4B
$HMSU,80,U,281.0,U,U,0,0,0*4B
$HMSU,80,U,280.6,U,U,0,0,0*4C
$HMAR,0,1,0,0,0,1*16
$HMSU,80,U,280.6,U,U,0,0,0*4C
$HMSU,80,U,280.3,U,U,0,0,0*49
$HMSU,80,U,280.3,U,U,0,0,0*49
$UCID,HeaterMeter,20140630B*3F
$HMSU,80,U,278.4,U,U,0,0,0*49
$HMAR,0,0,0,0,0,1*17
$HMSU,80,U,281.0,U,U,0,0,0*4B
$HMSU,80,U,280.0,U,U,0,0,0*4A
$HMSU,80,U,279.9,U,U,0,0,0*45
The rPI is type B version 2 with 512MB ram.
Last edited:
RalphTrimble
TVWBB Diamond Member
What about downloading the latest IMG file and rewriting the SD Card fresh and then trying to load the snapshot? Maybe something isn't quite right with your current build or maybe something has been updated in the pi firmware on the latest IMG that will make it work with your rPi? Drawing at straws and throwing out all ideas...
Last edited:
That die mot workshop als well. I got a new rPI today and that fixed the problem...
Bryan Mayland
TVWBB Hall of Fame
I know that the autobackup is currently not working properly on the snapshot. This comes from the way the time jumps forward on bootup interacting with the plugin system. I'm working on a solution but don't rely on the autobackup if you're going to pull the plug real quick to move the HeaterMeter or anything like that.
Bryan Mayland
TVWBB Hall of Fame
Autobackup should be fixed-- the graphs should persist across reboots and power losses again.
Also new
EDIT: Snapshot from 6pm now fixes inability to change probe type in the earlier snapshot.
Also new
- The PID I accumulated sum will now reset if you set the PID I constant to 0. I think this is the best compromise between people who want it reset of every change and those who don't.
- PID B has been removed from both the UI and the firmware. The PID I term should provide the same functionality
- Prevent the browser from getting bogged down the more times you updated configuration without a page reload occurring
- Fix linkmeterd plugins not being re-registered if you perform an "AVR Reboot"
EDIT: Snapshot from 6pm now fixes inability to change probe type in the earlier snapshot.
Last edited:
Bryan Mayland
TVWBB Hall of Fame
Added: Register the hostname from the System configuration if one is not specified in the dhcp client configuration.
How does this relate to:
http://tvwbb.com/showthread.php?55274-Latest-Software-LinkMeter-v12-and-firmware
http://tvwbb.com/showthread.php?55274-Latest-Software-LinkMeter-v12-and-firmware
Bryan Mayland
TVWBB Hall of Fame
v12 is the latest stable. The snapshot is the ongoing development, which may have bugs, but starts from v12.
Bryan Mayland
TVWBB Hall of Fame
I've put up a new AVR firmware in which I rewrote the servo movement routine.
I spent a lot of time this weekend trying to replicate the servo not moving to where it supposed to. I made a little cardboard rig with a pointer on the servo to make sure it consistently would go to the same place at the right output. I tried it with manual mode as well as with a thermometer and it always seemed to work as expected. I've gone over the code dozens of times looking for an edge case and I just can't find one. Until I can reliably reproduce it, I can't find a bug.
What I did change was how the servo operates. The old code would step between the current position and target position, assuming there would be 50 servo pulses between when it set the target and when the servo is deactivated. Two of these pulses could theoretically be lost as the first and last might occur mid-pulse. Because the value also changes mid-pulse, there's a chance for one of the two to be too long or too short, with a higher possibility of "too long". The servo always moved a constant speed of 1/50th of a position per tick.
Now the servo changes are all synchronized to period starts. In addition, the position changes are smoothly accelerated and decelerated so if it moves far you'll see it ramp up and down at he beginning and end. It also only takes ~35 of the 50 ticks to move into position, the last 15 are still ticked at the final position so if the servo got stuck somewhere along the way it still has a large number of ticks to get to the final place. I had also considered just moving the servo a fixed amount every period and just letting it take as long as it needed to get to where it was going (asynchronous to the once-per-second update) and deactivate after a timeout but the code for that was even longer and more complicated so let's try this first. Here's how the servo will move in the 20151013 AVR firmware.
I spent a lot of time this weekend trying to replicate the servo not moving to where it supposed to. I made a little cardboard rig with a pointer on the servo to make sure it consistently would go to the same place at the right output. I tried it with manual mode as well as with a thermometer and it always seemed to work as expected. I've gone over the code dozens of times looking for an edge case and I just can't find one. Until I can reliably reproduce it, I can't find a bug.
What I did change was how the servo operates. The old code would step between the current position and target position, assuming there would be 50 servo pulses between when it set the target and when the servo is deactivated. Two of these pulses could theoretically be lost as the first and last might occur mid-pulse. Because the value also changes mid-pulse, there's a chance for one of the two to be too long or too short, with a higher possibility of "too long". The servo always moved a constant speed of 1/50th of a position per tick.
Now the servo changes are all synchronized to period starts. In addition, the position changes are smoothly accelerated and decelerated so if it moves far you'll see it ramp up and down at he beginning and end. It also only takes ~35 of the 50 ticks to move into position, the last 15 are still ticked at the final position so if the servo got stuck somewhere along the way it still has a large number of ticks to get to the final place. I had also considered just moving the servo a fixed amount every period and just letting it take as long as it needed to get to where it was going (asynchronous to the once-per-second update) and deactivate after a timeout but the code for that was even longer and more complicated so let's try this first. Here's how the servo will move in the 20151013 AVR firmware.
RalphTrimble
TVWBB Diamond Member
OK, great I will update the firmware on my HM now and report back ASAP.
As for the issue, I know you weren't saying that it isn't happening, just saying you can't reproduce it... I can assure you that I have seen this happen more than a few times before I reported it and one other user also reported the servo not moving to the right spot at times (when closing). I'm not sure if this is the same other user that had the issue with the HM not following the Max/Startup Max properly after installing the firmware like I did, that problem went away after flashing the snapshot after de-selecting "Keep Settings", so I am not sure if these two issues may be related? IDK why that happened to me and at least one other guy, you couldn't reproduce that behavior either but it was definitely happening...
Right now I have what I would call the "golden servo" on my RD3, it's the best working servo I have come across. It moves strong, never chatters, never hangs, I've never had issue with it not doing it's job so I am pretty certain it isn't servo or damper related.
As for the issue, I know you weren't saying that it isn't happening, just saying you can't reproduce it... I can assure you that I have seen this happen more than a few times before I reported it and one other user also reported the servo not moving to the right spot at times (when closing). I'm not sure if this is the same other user that had the issue with the HM not following the Max/Startup Max properly after installing the firmware like I did, that problem went away after flashing the snapshot after de-selecting "Keep Settings", so I am not sure if these two issues may be related? IDK why that happened to me and at least one other guy, you couldn't reproduce that behavior either but it was definitely happening...
Right now I have what I would call the "golden servo" on my RD3, it's the best working servo I have come across. It moves strong, never chatters, never hangs, I've never had issue with it not doing it's job so I am pretty certain it isn't servo or damper related.