Propeller Router
Dr_Acula
Posts: 5,484
Over on this thread http://forums.parallax.com/showthread.php/156414-WiFi-amp-IOT-for-home-controllers-monitors-using-WR703N-20-routers-and-xx-WRT is some very interesting work interfacing a propeller to a router. Inspired by this, I've been pondering low power networks using RS232 and RS232 433Mhz wireless links that could link into the home controller wifi network.
The niche for this project is battery power. Wifi and Ethernet routers all use maybe 5V at 1A or 12V at 1A (they are getting less over time), and even if they use 1W, that will flatten batteries very quickly, and solar panels for 'out in the field' applications would need larger panels and batteries to cover the possibility of cloud cover for a week.
I have had simple networks working in the past. Perhaps the simplest one to explain is a 'single wire, multidrop' configuration. The wire is pulled high with a 10k resistor, and devices can talk to this wire with either Low or HiZ signals. The Propeller is perfect for doing this. Essentially this is the same hardware as the I2C bus.
But there is a catch - what I found in practice is that as one added devices, eventually data packets started to clash. And then you add a protocol to check whether a packet got through, and that adds more traffic and the whole thing becomes too slow. Also - if the wire is long, eg hundreds of metres, the baud rate needs to be slow (eg 1200).
So I have been thinking about better solutions. One concept is to have segments that can communicated at different baud rates - in a simplistic sense, if a wired segment is short, it can talk a lot faster. The first thing the propeller can do therefore is translate baud rates. This can be handy if, say, the GPS is 4800 baud, the comms to a PC are 115200, and the long wire connection is 1200 baud.
The next part is routing. Say two packets of data arrive at the same time and you want to send them on one after the other. The Picaxe chips really struggle with this task, as they hang when serial data is coming in. There are solutions but they require multiple chips. The Propeller, on the other hand, is perfect - use existing obex serial code with large buffers and assign cogs to each serial port.
The next part of the puzzle is the network topology. Star, round robin, single wire etc. There is a very simple topology where a router just splits a signal into two parts like a Y. So, tip the Y upside down and the top is now the top of the network. Now put some more upside down Ys underneath - each arm splits into two parts. Feed in a packet anywhere. Each propeller router takes that packet and sends it on up to the top of the network. At the top of the network, there is nothing special - no PC or fancy router. Rather, there is a D9 RS232 plug with pin 2 and 3 joined together. So packets go up to the top, then go down through the network to every part of the network.
Data only can clash going up the network to the top. Going down, it is just split (which could be in software, or even just done in hardware).
All packets now go to all parts of the network.
Next part - add wireless. Any part of a RS232 link can be replaced with a wireless link. There are some great modules around that are now under $10 which handle all the signal processing, and more importantly, can be programmed to all used different channels. So maybe a wireless link is slow at 1200 buad, but other parts of the wired network can be a lot faster.
Next part - real world interfacing. It would be very handy to be able to sense a value, or turn a relay on and off, and do this with data packets. I used an arduino pinout as there are many real world addon boards using this form factor.
Next thing - it would be handy to be able to display data packets. So add a TV display (eg a LCD car reversing display as these are very small and cheap).
And maybe it might be useful to configure things on the fly - eg the baud rate. Rather than add DIP switches, why not add a keyboard socket as this is so easy to do on the propeller.
And for good measure, an SD socket, though maybe this is overkill.
This could go further. The sockets can connect to a WZ5100 arduino ethernet shield and with the appropriate software, that could add an ethernet port. But I don't know if the software exists, and for connecting to Wifi and the ethernet, the solution being talked about in that thread above would be a better answer.
So - the niche here is the lower power part of the Internet of Things. The little robot that cleans the floor and charges up at the window with a solar panel. The moisture sensor in the garden running from a solar powered garden light. The current sensor on a mains wire that uses a current transformer to power itself.
Attached is a version 1.0 schematic.
Thoughts and ideas would be most appreciated
The niche for this project is battery power. Wifi and Ethernet routers all use maybe 5V at 1A or 12V at 1A (they are getting less over time), and even if they use 1W, that will flatten batteries very quickly, and solar panels for 'out in the field' applications would need larger panels and batteries to cover the possibility of cloud cover for a week.
I have had simple networks working in the past. Perhaps the simplest one to explain is a 'single wire, multidrop' configuration. The wire is pulled high with a 10k resistor, and devices can talk to this wire with either Low or HiZ signals. The Propeller is perfect for doing this. Essentially this is the same hardware as the I2C bus.
But there is a catch - what I found in practice is that as one added devices, eventually data packets started to clash. And then you add a protocol to check whether a packet got through, and that adds more traffic and the whole thing becomes too slow. Also - if the wire is long, eg hundreds of metres, the baud rate needs to be slow (eg 1200).
So I have been thinking about better solutions. One concept is to have segments that can communicated at different baud rates - in a simplistic sense, if a wired segment is short, it can talk a lot faster. The first thing the propeller can do therefore is translate baud rates. This can be handy if, say, the GPS is 4800 baud, the comms to a PC are 115200, and the long wire connection is 1200 baud.
The next part is routing. Say two packets of data arrive at the same time and you want to send them on one after the other. The Picaxe chips really struggle with this task, as they hang when serial data is coming in. There are solutions but they require multiple chips. The Propeller, on the other hand, is perfect - use existing obex serial code with large buffers and assign cogs to each serial port.
The next part of the puzzle is the network topology. Star, round robin, single wire etc. There is a very simple topology where a router just splits a signal into two parts like a Y. So, tip the Y upside down and the top is now the top of the network. Now put some more upside down Ys underneath - each arm splits into two parts. Feed in a packet anywhere. Each propeller router takes that packet and sends it on up to the top of the network. At the top of the network, there is nothing special - no PC or fancy router. Rather, there is a D9 RS232 plug with pin 2 and 3 joined together. So packets go up to the top, then go down through the network to every part of the network.
Data only can clash going up the network to the top. Going down, it is just split (which could be in software, or even just done in hardware).
All packets now go to all parts of the network.
Next part - add wireless. Any part of a RS232 link can be replaced with a wireless link. There are some great modules around that are now under $10 which handle all the signal processing, and more importantly, can be programmed to all used different channels. So maybe a wireless link is slow at 1200 buad, but other parts of the wired network can be a lot faster.
Next part - real world interfacing. It would be very handy to be able to sense a value, or turn a relay on and off, and do this with data packets. I used an arduino pinout as there are many real world addon boards using this form factor.
Next thing - it would be handy to be able to display data packets. So add a TV display (eg a LCD car reversing display as these are very small and cheap).
And maybe it might be useful to configure things on the fly - eg the baud rate. Rather than add DIP switches, why not add a keyboard socket as this is so easy to do on the propeller.
And for good measure, an SD socket, though maybe this is overkill.
This could go further. The sockets can connect to a WZ5100 arduino ethernet shield and with the appropriate software, that could add an ethernet port. But I don't know if the software exists, and for connecting to Wifi and the ethernet, the solution being talked about in that thread above would be a better answer.
So - the niche here is the lower power part of the Internet of Things. The little robot that cleans the floor and charges up at the window with a solar panel. The moisture sensor in the garden running from a solar powered garden light. The current sensor on a mains wire that uses a current transformer to power itself.
Attached is a version 1.0 schematic.
Thoughts and ideas would be most appreciated
Comments
Bifurcation - elegant and a highly practical non-wireless solution. The scalability may suffer though where there is high baud input but slow(er) throughput on a leg/arm.
The four port serial object could handle 3 downstream ports and one high speed up stream port.
A single propeller could run 2 copies (or more) of the four port serial object.
For the upstream ports you could use RS422/RS485 for higher speed or longer distance.
Good ideas. I'll add to the schematic and repost. Cheers
I considered a serial terminal router some years ago. I'm sure I got distracted ;-) Actually one of the boards I designed was used for my 3 AXIS CNC mill demo way back then.
My main quandary was deciding whether ports should be full RS232C on 9 pin D shell, or some other interface. When it came down to it, I thought a "front-end" plugin board was the right thing to do to keep things flexible.
The EELive expo this year was all about the "Iot" stuff. Seems like everything needs some kind of a wireless connection. The power required for such things seem relatively excessive.
Yes. And if anyone was silly enough to try and push a higher data rate than the system is designed for, well ....
And rather than or as an add-on, RS422/485?