The SMS gateway worked between the sensor RF network and the mobile phone network. However, it lacked sensitivity, occasionally struggling to get a signal 20 yards away.
Ciseco OpenKontrol Gateway on lid of device, with Dallas 1307 RTC implemented
I mounted the OKG board on the lid of the box and the SMS board in the base, unwittingly placing the sensor RF receiver between two ground planes. And a mobile phone signal source in a similar part of the radio spectrum. Which was probably not the best way to get good performance out of the LLAP sensor radio – screen it and then desensitise it with a strong nearby signal. Oops. Continue reading “Improving the coverage of the sensor radio network”
Ciseco’s LLAP format is a nice lightweight and PIC microcontroller and Arduino friendly serial protocol. I use their XRF modules for RF communication, these support power-down so they are well-suited to intermittent operation off a battery. Standing current on receive is 23mA so continuous operation is more of a challenge, for instance at the RF to SMS gateway. It has 12 bytes like so:
LLAP Message format
Each message is exactly 12 characters long and in three distinct sections:
See Appendix 3 for details of the permissible characters in each field.
Their examples, however, send only one data value per LLAP message, with a descriptive section. Hence
aAATMPA12345
Which is wasteful IMO. A lot of sensors have two data points,for instance temperature difference measurements, or temperature and relative humidity.
Few real world sensors can justify the precision of using all the digits; I don’t have any with an accuracy of more than three digits. Sensing temperature to an accuracy of 0.1C is unusual – the popular dalas 18B20 is accurate to 0.5C but to do much more implies a piece of laboratory equipment. Useful values of temperature in the UK would be -20 to 120 °C, Relative humidity is 0 to 100 – cheap sensors don’t really justify a .x so allocating four digits covers most bases. Negative values give the ugly -21. as the – takes up a digit but it’s only a machine that sees it. So I can make a double density device as
aAA12.34X5.67
and keep within the spec. I use **** for failed or missing sensors, and the X is replaced by L,M or H for battery status. M and H are operational, L means may be about to switch off in a few cycles. In sensors that support H then M means would still accept charge, H is enough. However I use a simple comparator at about 4.4 V on a PIC 16F628 so I can only show L and M.
This saves me precious power, and allows me to consolidate two temperature sensors to one radio saving cost of the radio and aggravation of maintaining batteries.
two-sensor PIC and XRF device
I couldn’t use JAL for this because I laid out the board to use the 16F628’s internal oscillator that runs at 4MHz and the JAL one-wire lib wants to run at 20MHz. So I had to code it in assembler 🙁 Next time I’ll leave space for a 20MHz resonator on the board that will save me all that grief.
I now get to read two temp sensor and the battery status, all in one LLAP message 🙂
Wires. That’s the problem with remote sensing, at least it has been until recently. You needed wire to get the signal back to where you wanted to view it, and often to power your sensor too. That’s a grand PITA. The last time I looked at this, about a decade ago, you could get little RF modules running at around 433MHz but these presented the raw demodulated FM signal. Great for voice but you then needed a modem to wrap around the project. And some sort of protocol stack, possibly.
That exchanged the signal wiring problem for a sensor powering issue, and these radio modules were send or receive so everything would end up fire and forget.
I was chuffed to find there’s been a lot of movement in this field. A lot of it seems Arduino based and I selected PICs when getting into micros, so it is a new learning curve. In researching this I came across JeeLabs and Ciseco. The latter had some £12 bidirectional RF to serial cards, the XRF, which I expected to attach a PIC. However, they seeme ot also have used the microcontroller on the RF board to do some signal conditioning for a few sensors, including temperature via the Dallas 18B20 or a thermistor. Since temperature and battery voltage/contact status are some of the things I want to remote sense that saves me a load of programming grunt-work.
They have also documented a simple serial sensor protocol, LLAP, which fitted my needs. The Internet of Things is all very well but if you need a TCP/IP stack for each battery powered node you need a lot of processing power and electrical power, which is back to wiring again.
So I ordered four XRF boards, a couple of thermistor boards and a XBBO carrier board to interface to an FTDI cable to USB. Assembling the thermistor boards and the XBBO were easy enough, now it was time to test it all out and getting some readings. To do that you have to set your LLAP sensor device to some particular address. and this is where is started getting hard. You have to program them over the air, and you have 100ms to respond to the started command.
Ciseco XBBO board for LLAP devices
That’s great for security, but I don’t type that fast 🙂 Which is why I use this script to do that job.
Wires. That’s the problem with remote sensing, at least it has been until recently. You needed wire to get the signal back to where you wanted to view it, and often to power your sensor too. That’s a grand PITA. The last time I looked at this, about a decade ago, you could get little RF modules running at around 433MHz but these presented the raw demodulated FM signal. Great for voice but you then needed a modem to wrap around the project. And some sort of protocol stack, possibly.
