@emdeex unfortunately modbus is just a protocol, and doesn't really solve the whole stack problem, Much like panStamp which is where I feel they have dropped the ball somewhat. My personal feeling is restricting an app server (which is really what the lagarto server component is) to a single protocol (modbus, SWAP, Zigbee etc.) totally limits what you can do. We live in a world with things like JeeNodes, 433Mhz power monitors, weather stations, X10 devices, zigbee, modbus etc..... All of these are just channels for getting data out of sensors and controlling physical things.
So I am looking for a pluggable solution. It exists for web application development and I think it shouldn't be too hard (famous last words ;-) to do for sensors and physical devices.
I think there are some Java based solutions, but I just can't be bothered with java, I was there (@sun) when it started and it was light weight (intended for set top boxes and handhelds)_, and watched it grow into this behemoth very rapidly.
I know it isn't very clean but you could just have a minimal JeeMon to capture the messages and then pass them onto a separate piece of hardware/software of your choosing. This is what I do, everything that arrives in JeeMon is forwarded to a BASH script where I chop it up and pass it onto my other HA stuff. The HA and JeeMon share the same hardware platform - a Sheevaplug.
This was similar to what I was thinking. I posted a few days ago about Modbus, and how a 30 year old protocol still serves the needs of thousands of industries, vendors and devices, and why there was not something similar for wireless sensors.
Daniel at panStamp says he has studied the modbus system, to come up with SWAP, a simple protocol system for wirless sensors. So I'm wishing him all the best and I'm looking forward to getting some to play with.
At first glance I thought Jeemon was what I needed as well, and it might be, but I'm getting a headache thinking about learning another language.
I'll keep exploring and looking for that solution, and let you know.
Thats a pity. There are a few sensor network server software stacks out there, but most seemed wedded to a single protocol stack or family of devices, or have limited focus like http://code.google.com/p/open-zb-home/
If I where building one (maybe I will ;-) I would completely seperate the client/agents, have a centralised bus linking everything, a datastore component, a seperate reporting/graphing component, and control/event framework. That way each piece could be replaced. Maybe it's out there (I think I just described JeeMon ;-) But unfortunately tcl makes my eyes bleed ;-) so I have very little inclination to go down that path.
@jbeale, this links in with the DFfsk parameter setting on the receiver side - the maximum pull in range of the AFC is 0.8*DFfsk.
Not quite so stringent on the tolerance required for the crystals - the sidebands spread well beyond the 'bats ears' and the input filter is not a brick wall cutoff. A more reasonable estimate comes from the AFC range - taking 45kHz deviation puts the maximum crystal spread budget at ~39ppm, just workable for a 20ppm spread each.
Based on actual measurements, the SMD crystal spread a a reasonable fit to a normal distribution better than 20ppm
@timhoffman Thanks for that idea, I did contact the developer. He thought it would be hard to integrate with jeenode, as the Panstamp uses his SWAP protocol which was specifically built for the TI CC11XX radios.
Ok, I see one reason why you would want to use the +/- 90 kHz deviation setting. According to p.32 of the RF12B manual at http://www.hoperf.com/upload/rf/RFM12B.pdf
+/- 90kHz deviation is the smallest value that you can still use a 25 ppm tolerance crystal in the 915 MHz band (assuming 38.3kbps bitrate, or higher). With any smaller deviation setting, you would need a more accurate crystal to make sure the TX and RX units could hear each other. At +/- 45 kHz you would need a 3 ppm crystal(!) Even if it was ok to start, it might drift too much over temperature or from aging. Also the "optimal settings" page on p.37 does show 90 kHz.
Sounds like I need to expand my flashing LED a bit.
Tried your suggestion of feeding the supply after the regulator on a port connector and it works fine.
Not sure what's going on as I measured the voltage at the DS18B20 supply and it was 3.2V (feeding prior to the regulator) and this is within the spec of the DS18B20 (3.0 - 5.5V)
Some more investigation I think.
I had a bigger panic when I started, the GLCD wouldn't initialise at all but I found that I wasn't calling a refresh in the setup so the static text wasn't being drawn and the screen was just random dots, I thought I'd broken the GLCD.
Damn, I just realised that means the receiver wasn't receiving any RF data because the first refresh was in the rf12_recvDone() if statement, it looks like the RFM12 wasn't sending out, more investigation required.
I wonder at what level the linker discards elements. If one is using rf12.cpp are the deprecated routines discarded, assuming they are not referenced by the main code. In case you are wondering, I have been surprised just how quickly the 8meg in my ATMEGA8 is eaten up. I guess I should investigate the .lst file of something. Is there a linkage editor map somewhere under the covers?
Discussion about JeeLabs projects
@emdeex unfortunately modbus is just a protocol, and doesn't really solve the whole stack problem, Much like panStamp which is where I feel they have dropped the ball somewhat. My personal feeling is restricting an app server (which is really what the lagarto server component is) to a single protocol (modbus, SWAP, Zigbee etc.) totally limits what you can do. We live in a world with things like JeeNodes, 433Mhz power monitors, weather stations, X10 devices, zigbee, modbus etc..... All of these are just channels for getting data out of sensors and controlling physical things.
So I am looking for a pluggable solution. It exists for web application development and I think it shouldn't be too hard (famous last words ;-) to do for sensors and physical devices.
I think there are some Java based solutions, but I just can't be bothered with java, I was there (@sun) when it started and it was light weight (intended for set top boxes and handhelds)_, and watched it grow into this behemoth very rapidly.
I know it isn't very clean but you could just have a minimal JeeMon to capture the messages and then pass them onto a separate piece of hardware/software of your choosing. This is what I do, everything that arrives in JeeMon is forwarded to a BASH script where I chop it up and pass it onto my other HA stuff. The HA and JeeMon share the same hardware platform - a Sheevaplug.
This was similar to what I was thinking. I posted a few days ago about Modbus, and how a 30 year old protocol still serves the needs of thousands of industries, vendors and devices, and why there was not something similar for wireless sensors.
Daniel at panStamp says he has studied the modbus system, to come up with SWAP, a simple protocol system for wirless sensors. So I'm wishing him all the best and I'm looking forward to getting some to play with.
At first glance I thought Jeemon was what I needed as well, and it might be, but I'm getting a headache thinking about learning another language.
I'll keep exploring and looking for that solution, and let you know.
Thats a pity. There are a few sensor network server software stacks out there, but most seemed wedded to a single protocol stack or family of devices, or have limited focus like http://code.google.com/p/open-zb-home/
If I where building one (maybe I will ;-) I would completely seperate the client/agents, have a centralised bus linking everything, a datastore component, a seperate reporting/graphing component, and control/event framework. That way each piece could be replaced. Maybe it's out there (I think I just described JeeMon ;-) But unfortunately tcl makes my eyes bleed ;-) so I have very little inclination to go down that path.
Cheers
Tim
@jbeale, this links in with the DFfsk parameter setting on the receiver side - the maximum pull in range of the AFC is 0.8*DFfsk.
Not quite so stringent on the tolerance required for the crystals - the sidebands spread well beyond the 'bats ears' and the input filter is not a brick wall cutoff. A more reasonable estimate comes from the AFC range - taking 45kHz deviation puts the maximum crystal spread budget at ~39ppm, just workable for a 20ppm spread each.
Based on actual measurements, the SMD crystal spread a a reasonable fit to a normal distribution better than 20ppm
@timhoffman Thanks for that idea, I did contact the developer. He thought it would be hard to integrate with jeenode, as the Panstamp uses his SWAP protocol which was specifically built for the TI CC11XX radios.
@tankslappa - not worthy of that hot air gun, it's just a wire tack job! (and then a cap to ground to hang somewhere)
Ok, I see one reason why you would want to use the +/- 90 kHz deviation setting. According to p.32 of the RF12B manual at http://www.hoperf.com/upload/rf/RFM12B.pdf +/- 90kHz deviation is the smallest value that you can still use a 25 ppm tolerance crystal in the 915 MHz band (assuming 38.3kbps bitrate, or higher). With any smaller deviation setting, you would need a more accurate crystal to make sure the TX and RX units could hear each other. At +/- 45 kHz you would need a 3 ppm crystal(!) Even if it was ok to start, it might drift too much over temperature or from aging. Also the "optimal settings" page on p.37 does show 90 kHz.
Sounds like I need to expand my flashing LED a bit.
Tried your suggestion of feeding the supply after the regulator on a port connector and it works fine.
Not sure what's going on as I measured the voltage at the DS18B20 supply and it was 3.2V (feeding prior to the regulator) and this is within the spec of the DS18B20 (3.0 - 5.5V)
Some more investigation I think.
I had a bigger panic when I started, the GLCD wouldn't initialise at all but I found that I wasn't calling a refresh in the setup so the static text wasn't being drawn and the screen was just random dots, I thought I'd broken the GLCD.
Damn, I just realised that means the receiver wasn't receiving any RF data because the first refresh was in the rf12_recvDone() if statement, it looks like the RFM12 wasn't sending out, more investigation required.
Thanks for the help.
I wonder at what level the linker discards elements. If one is using rf12.cpp are the deprecated routines discarded, assuming they are not referenced by the main code. In case you are wondering, I have been surprised just how quickly the 8meg in my ATMEGA8 is eaten up. I guess I should investigate the .lst file of something. Is there a linkage editor map somewhere under the covers?