12-02-2016, 18:21
Hi Werk_AG,
Thanks for your reply; yes that's rather what I expected, but your links have helped me to look deeper into "VirtualWire". I don't believe anybody has ported that to the (PICaxe*) processor that I'm using, so I may have to do it myself. I'm reasonably happy wth the run-in ("training") and message data, but am always worried about CRCs, because they are hard to debug if they don't work (especially if you don't understand the maths). I see it employs a 16-bit library for the CRC, but does it use only 8 bits?
AFAIK the Fine Offset data can be decoded by "bit banging" in much the same way as I believe you used for the Auriol protocol. It uses a long/short pulse coding for 0/1, the first byte always "FF", then the address/message data and finally an 8-bit CRC. Adding a FO reception protocol might be useful for many users, because there are so many FO stations "out there". But it is probably not the best use of your time. However, if you decide it is worthwhile, then I should be able to at least confirm the message data format(s). The FO "Solar Pod" sends data only in "coded" format, but I haven't seen the Pods available as a "spare part" anyway. Also, the "Solar" coding format is not very versatile - 3 bytes (22 bits theoretically used) for the "Lux" value, but only 4 bits for the UV (i.e. UVIndex = 0 to 15 in integers).
Also, I note from another thread that WeatherDuino uses a 9+ volts supply for the transmitter, whilst FO use 3 volts (or less). That may (partly) explain why the FO wireless link is so "Iffy" (not sure if that translates into Portuguese).
* The reason that I use PICaxe is because it can potentially operate at power levels "compatible" with the Fine Offset battery-powered systems (i.e. 3v from 2 x AA cells). Thus the "design target" for my "compatible" solar pod design is to use a 50 milliwatt PV panel (from a solar garden light) for the power, with an average power consumption of <1 milliwatt. That's one reason my progress is so slow.
Cheers, Alan.
Thanks for your reply; yes that's rather what I expected, but your links have helped me to look deeper into "VirtualWire". I don't believe anybody has ported that to the (PICaxe*) processor that I'm using, so I may have to do it myself. I'm reasonably happy wth the run-in ("training") and message data, but am always worried about CRCs, because they are hard to debug if they don't work (especially if you don't understand the maths). I see it employs a 16-bit library for the CRC, but does it use only 8 bits?
AFAIK the Fine Offset data can be decoded by "bit banging" in much the same way as I believe you used for the Auriol protocol. It uses a long/short pulse coding for 0/1, the first byte always "FF", then the address/message data and finally an 8-bit CRC. Adding a FO reception protocol might be useful for many users, because there are so many FO stations "out there". But it is probably not the best use of your time. However, if you decide it is worthwhile, then I should be able to at least confirm the message data format(s). The FO "Solar Pod" sends data only in "coded" format, but I haven't seen the Pods available as a "spare part" anyway. Also, the "Solar" coding format is not very versatile - 3 bytes (22 bits theoretically used) for the "Lux" value, but only 4 bits for the UV (i.e. UVIndex = 0 to 15 in integers).
Also, I note from another thread that WeatherDuino uses a 9+ volts supply for the transmitter, whilst FO use 3 volts (or less). That may (partly) explain why the FO wireless link is so "Iffy" (not sure if that translates into Portuguese).
* The reason that I use PICaxe is because it can potentially operate at power levels "compatible" with the Fine Offset battery-powered systems (i.e. 3v from 2 x AA cells). Thus the "design target" for my "compatible" solar pod design is to use a 50 milliwatt PV panel (from a solar garden light) for the power, with an average power consumption of <1 milliwatt. That's one reason my progress is so slow.
Cheers, Alan.