RF stability issue?
2 May, 2011 - 08:02
Sorry folks but am I noticing an issue with the rf system, in that it will not transmit rf signals if the livebox has been up and running for any length of time (I approximate about 8 hours of up time) I am currently trying to get more info on exactly when this stops working but a reboot cures everything again for another length of time. (for interest XFX shows the xap messages to be present and physical relays work, its just the rf does not transmit)
Any ideas on what to check, where to start bebugging, etc. would be most appreciated. I currently have a reboot script to "mask" this issue so can live with it but have read that Derek had some stability issues and thought you might like to know about it.
Current system:
Firmware 279.13/2.2
ATMEGA328
PS I did remove my scripts to check It wasn't me creating the issue.
thanks
Garry
3 May, 2011 - 13:19
#3
That error
This would imply that the RF string being sent is invalid.
The RF HEX sequence breaks down like this
<VERSION (byte)><BIT PER FRAME <byte)>....
The error you are getting implies you are sending a string that start like this 015A.... As 90 dec is 5A hex.
The only valid number for BIT PER FRAME are 01/02/04 -- so 5A is an invalid encoding so it breaks.
What is the complete string you are sending?
3 May, 2011 - 18:16
#5
Version reporting
If the web gui is reporting /1.0 then it thinks you have a M8 chip - once this happens NO RF will work as it will be sending the wrong commands to the AVR chip.
What is suppose to happen is this:
xap-livebox starts up and sends a "version" string to the AVR the M8 has no command for this so it does not send anything back the xap-livebox process times out after 300ms (i think) and defaults back to 1.0. The 328 chip has a "version" command so it reports something at the moment "2.2"
Something in this process above is not working correctly.
NOTE: If you enter DEBUG mode on your AVR you ABSOLUTELY MUST drop it back out of this mode before exiting micrcom, by entering "debug" again, even a reboot of the HAH won't fix it as the AVR is not rebooted!
Alternatively you can POWER cycle the entire unit.
4 May, 2011 - 07:36
#7
Stack corruption
It looks to me as if the bascom stack might be being corrupted. Compared to anything else that is done in the code, URF uses very long strings.
I'd like to understand whether the issue comes in over 'time' or over the 'number of URF calls'. If we know this, we can better work out where to go a hunting for an issue. We might also try turning interrupts off a bit earlier in the URF processing. I'll have a chat with Brett to get some ideas going.
I'm away from base this week, so can't get to actually trying anything 'till the weekend.
Do let us know if you have any other observations.
Cheers,
Derek.
6 May, 2011 - 14:10
#9
Think I found the problem
In the 1wire interrupt vector it was using a variable that was also being used by the URF routine and others. So if the code just happened to be in the middle of processing the URF command string and it was time to poll the 1wire sensor a crucial variable was being overwritten.
I've uploaded v2.3 to fix this. If you are on v2.2 try disconnecting the 1wire sensor to see if URF becomes stable. If this cure the problem then we will know 100% that this was issue, however I'm pretty confident it was.
Update: Eyeballing the code again I'm now less than confident. Damn this code is fugly. Working on another theory.
Brett
19 June, 2011 - 08:23
#10
Any progress?
I have just updated to the 328 and find I am having the same issue with my bye bye standby plug units. If I send an ON command from the web interface page it works for a while, however after a few hours the RF doesn't respond unless I reboot the HAH. Other functions seem to work but the only reason for upgrading was to use the universal RF.
Has anyone got to the bottom of the issue?
Thanks
Mike
19 June, 2011 - 10:48
#11
Not yet ...
Last I did on this was to setup a rig with just RF and sent a 'toggle' to a Lidl socket every 10 secs.
--[[
Send URF a command every 10 seconds to toggle something on/off
--]]
module(...,package.seeall)
require("xap")
info = {version="0.04", description="URF tester"}
toggle=true
function init()
xap.Timer(dourf, 10):start()
end
function dourf()
-- HE on/off - Adjust as you want
if toggle then
cmd = "010201130A7301130113011304C9011300000C0127104219A6599A59A59A6659A5A666599A65A5B0"
else
cmd = "010201130A7301130113011304C9011300000C0127104219A6599A59A59A6659A5A6665999A5A5B0"
end
toggle = not toggle
xap.send(string.format([[
xap-header
{
v=12
hop=1
uid=FF00EE00
class=rf.xmit
source=dbzoo.fake.source
target=dbzoo.livebox.Controller
}
rf
{
data=%s
}]],cmd))
end
This ran for 4 days without issue ... BUT there was no I2C bus activity, nor was there any CurrentCost feed.
I haven't been home enough in the past few months to make headway on this (and am headed away again this week). So, I've just packed a 'portable HAH test rig' complete with AVR programmer board, I2C temp sensor and an RF socket. Damn, this lot won't look good as handbaggage!
Plan is to run up the shipping 328 & get the problem reproduceable. Then to up to the very latest Bascom from Brett & see if that improves matters.
I'll report any findings here. If anybody who has the 328 can offer any debug findings, that would be appreciated.
We'll get to the bottom of this one!
Derek.
20 June, 2011 - 06:57
#12
debug info
In debug mode when it fails microcom reports
urf 010177046504650177060127101914101500
Bad encoding of 58
RF setup failed
The Report on 1 wire is sometimes incomplete, sometimes missing a carriage return or missing part of the line as if it doesn't have time to output all the ROM ID
It doesn't matter which RF channel I use it says Bad encoding of 58
I have a CC128 current cost meter connected but no I2C devices. There are 2 temperature sensors on the 1wire
Don't know if this helps?
Mike
20 June, 2011 - 13:11
#13
BASCOM memory issue
Given BASCOM is really shitting me off trying to figure out why this urf code is breaking - I've decided to rewrite the entire AVR firmware into C/C++.
I've ran into many issues before with BASCOM's such as it's inabilty to correctly handle function framing and passing local stack based variables, which already entailed a rewrite which is why the current code has so many global variables. I'm thinking that this URF issue just another BASCOM madness point and its pushed me over the edge. So now is a good time to sort this out once and for all and throw it all away and start again.
To date my new code compiles up, but I've yet to flash it and try it out. I have however verified the URF piece runs correctly on a MBED ARM chip without any problems, and that the command processor/inputs/1wire etc seems to be behaving. Currently there is no I2C support as this requires bitbang I2C routines which I've not got around do doing. As there is no ISP header on the HAH board debuggin will require lots of pluging and unplugging of the 328 for testing. Which means its a good time to sort out a 115200 baud bootloader so AVR updates can be flashed from the HAH itself.
All this is going to be a rather large amount of work and will take me a little while to get together, as I'm moving house in about 5 weeks. Not to mention my day job and looking after my 1yr old on weekends. But stay tuned I'll do my best to get this sorted - If anybody has the time and expertise to help out let me know. Perferably skilled in: C/C++, Bootloaders, Hardware and the Arduino dev tools. Although I can cross compile up avrdude for MIPS (Livebox) easy enough.
Brett
7 November, 2011 - 21:05
#14
I am having a similar problem
Xap-snoop shows command being received but the rf is not transmitted running latest everything and rf fails within 30 minutes, sometimes within 5.
a reboot fixes it for a little while
anyone experiancing a similar problem?
7 November, 2011 - 22:55
#15
AVR Firmware releases
1.0 was for the M8 AVR chip (BASCOM) Hardcode for either LIDL or Bye Bye Standby depending on your release.
2.x firmware was targetted for the AVR 328 and was the 1st to include Universal RF (BASCOM)
3.x firmware was also for the AVR 328 but I rewrote it all in C.
The latest is v3.4
Brett
8 November, 2011 - 08:05
#16
289/2.4
My Livebox is 289/2.4 so i assume that means its avr 2.4?
to upgrade to 3 i hvae 2 choices HAH-52 or buy a new chip.?
How easy is it to re-burn my existing chip?
Dean
8 November, 2011 - 10:09
#17
Easy to reburn
289/2.4 is indeed AVR 2.4
HAH-52 requires that you have your own AVR STK-500 style programmer.
Instructions for burning you own chip are at http://www.dbzoo.com/arduino/isp_with_stk500 - it's not too difficult.
Derek.
8 November, 2011 - 11:30
#18
Ill just order a chip :)
At leat then i have 2 328's so i can then look at ordering programmer etc..
Dean
Hi Garry,
Thanks for the heads-up on this. We did see this behaviour when we first cut the URF code. However, we then upped the Bascom stack frame sizes & also upped the version of Bascom that we were using.
I then soak tested a unit for a week with occasional RF transmissions to a Lidl socket. This was good. The unit also had relays working, a CurrentCost attached and a few temperature sensors.
It would be very interesting to see what the AVR is responding with when the URF command is being issued by the HAH. If you kill the xap-livebox process and use microcom to connect directly to the AVR, you can issue URF commands interactively. Note that commands must be in lowercase.
One other thought ... did you use your own Bascom to compile up/load the image or was the chip pre-supplied with the code in place?
Cheers,
Derek.