Internet gateway to picaxe network using UDP through SimpleLan

lbenson

lbenson

Senior Member
http://www.omnibuslinx.com:7979

The above link is to a SimpleLan hosted web site, with a picaxe-powered (28X1) back end. It is offered as one way to realize Dr_Acula's proposal for a world-wide network of picaxe networks (tho it could connect to any microprocessor network).

This is only a partial, and tentative implementation. At its heart, it relies upon the internet UDP protocol to receive and transmit messages. The web site is relatively self-documenting. It has links for message format documentation, a simple schematic, UDP talker and listener code for the PC, and an option for simulating a UDP message for the gateway to act upon, all hosted on the SimpleLan module. I would host the picaxe code as well, except that the SimpleLan only has 31K of web storage, and with the other pages, the code text, at over 660 lines and nearly 20K, would overflow the storage.

Provision has been made for Dr_Acula-style and Kranenborg-style messages, as well as messages understood by the local attached picaxe. There is no picaxe network currently connected, but the gateway can respond to messages to supply the date, the time, and the temperature by reading local sensors (DS1307 and DS18B20), and can simulate the toggling of switches in response to messages.

Intended future development:

1. add a picaxe network.
2. proceed further with the relaying of messages when the network picaxe doesn't know the ip of the site to which it is sending the message (but the gateway does).
3. log all messages
4. parts list (28X1, SimpleLan, DS1307, DS18B20, 24c32, etc.)
5. improve error handling

The web site may be reached at http://www.omnibuslinx.com:7979. The Simplelan sends and receives only on port 22002. A UDP message in the proper format sent to 69.17.65.22 will respond according to the message sent. It will be necessary to refresh the screen on the web site to see the results.

Note that this implementation is only meant as an example. Anyone actually having devices to control remotely is not likely to want to have the interface this open and unprotected. To make this more of a black box, one could simply do away with the web interface and somehow encode the messages, perhaps using some kind of daily cipher change.

The presentation is not glitch-free--sometimes the site appears unavailable, but usually a refresh will bring it up again. It is most likely to fail in presenting graphics--the schematic or the little "on" and "off" switch setting indicators. Retrying will usually work.

Thanks to all contributors on the picaxe forum. After a career in software, the past eleven months on the hardware side have been quite a learning experience for me.

Any suggestions are welcome.

Lance
 

Attachments

  • 28Gateway2.jpg
    28Gateway2.jpg
    84.9 KB · Views: 190
Last edited:
Interesting, I tried to simulate a udp message to return the date but it didnt send anything, maybe my message was wrong.

But is the main idea that it can relay messenges between picaxes, and also provide various services for these (clock, date, interfaceing to other protocols, etc) ?
-How do you keep track of who uses which callerids ?


If so, by making atleast the first byte non-ascii, you could have 255options instead of 10 :)

The relay part of the gateway could be hosted on a regular server with database and stuff to make it easyier to keep all messenges, if you are going to provide a client initiated store-and-forward system
 
Mora99 --I don't think your message was wrong--there may be something wrong in the hosting site's forwarding of UDP messages out. In is working--I could see your request. Or I may have broken something in the code--it has worked on my local network. Unfortunately, I won't be able to fix it for a while--it's hosted at another location, and I'm about to leave for a week for the Thanksgiving day holiday. I'll look into it and see what I can find.

>by making at least the first byte non-ascii, you could have 255 options instead of 10

I used as my examples ASCII (and in fact, numeric: 0-9) codes for ease of debugging. The local host could interpret any code. The "local host" mode was kind of an afterthought so I could easily simulate connection to a picaxe network.

>is the main idea that it can relay messenges between picaxes, and also provide various services for these (clock, date, interfacing to other protocols, etc) ?

Yes--between picaxes or between any systems which want to communicate via the web.

>The relay part of the gateway could be hosted on a regular server with database

I thought the cool part was eliminating the "regular server"--but, yes, this could easily be done on a PC, and has been done by Dr_Acula.

>How do you keep track of who uses which callerids

I keep a ring buffer in EEPROM with 16 entries to keep track of the ips and message numbers; responses from the internal network would be linked back by message number. The need to keep track thus is the reason for adding message numbers (at least internally) to the Kranenborg message format--so I could know which ip to return the message to.
 
Great, it appears to work!

It responded properly to two commands I sent (switch setting and temperature reading)

Regards,
Jurjen
 
Very impressive Lance! You actually made the first step towards a new communication system between PicAxes.

I wonder if it would be possible to implement a ZigBee like network over the Internet. This way it would be possible to actually use PicAxe-based Wired Sensor Networks. I'm still waiting for my 28X1 chip (it's on it's way...!) so I can also help you out test the system.

Stelios
 
Stelios, Thanks--your work first put me on to the SimpleLan. What are the ZigBee-like aspects that you were thinking of? Is there a particular message protocol? Knowing little about ZigBee, I thought of it only as a (robust, powerful, $$, wireless) transmission mechanism.

Dr_A. As Mora99 said, SimpleLan doesn't do ftp. I was thinking of it as an alternative to the PC-based "gateway" mechanism which you published. This would provide the same functionality, without the PC, using the UDP messaging system.

I think my next step is to tie it to a Kranenborg-style network if I can figure out how to connect the 28X1 to that network as a self-powered node (the SimpleLan module seems to add over 100ma to the current draw--not quite as much as their documentation says).
 
UDP support added to PicaxeNET library

I've added UDP support to my connector library. You should be able to use the new UDPSender object in place of the WebSender object and it should just work(tm).


I've uploaded a new version of the file, I fixed a pretty severe bug that kept the UDP sender in an infinite loop.

(for those of you keeping score, this is a different address than the one I used to use. Please adjust your browsers accordingly)
 
Last edited:
puddlehaven--I just sent it a udp message and it responded (you have to refresh the web site screen after some seconds--it took two refreshes in my case). I can see that it has been power-cycled--I don't know when, I'm about 1,000 miles away now. My test was successful at 5:05pm US Central time. The message was to 69.17.65.22:22002. I see that I had the first number in the first post incorrectly as "60"--I've changed that.
 
I must be doing something wrong. I can't get the Web site to come up in my browser at all, I just keep getting timeout errors.

Am I supposed to be using my browser? On the HTTP address you have in your message?

I'll keep trying.

(later)
I was able to get a response from the SimpleLan and to test my PicaxeUDPSender object. I worked out a bug in the sender and now it's working.

It looks like I need to add a "UDP connector" object, since the SimpleLAN can return data as well. That's a project for after the 22nd (Thanksgiving holiday here in the States).
Chuck
 
Last edited:
Lance with ZigBee you can have a fully meshed network topology. Every node can forward it's messages or relay other nodes messages until they end up to the Main Node. This message auto-routing mechanism makes the ZigBee pretty much fault tolerant. If the neighboring node is dead another routing path will be created to pass the messages. I tried finding some info about the internals but it seems that there is no Open Source stack available.

Dr_Acula why would you need a common data repository? Are you interesting in a Data Acquisition model based on SimpleLan sensors?
Or, are you proposing a micro-IRC model (internet relay chat) functionality so every PicAxe sends and receives messages to a centralized location? Setting a tiny UDP server to store and forward messages among the PicAxe chip should be easy enough. I'm willing to help out with the software (Python?) and tests.
 
puddlehaven--the link in the first message above works for me; I'm 1,000 miles away using a dial-up internet connection. I can see from the web site that others have successfully been accessing the SimpleLan.

Stelios--I do not understand the advantage of UDP "forwarding" (as opposed to using UDP messaging to connect to off-the-net microprocessors). If site A knows the ip address of UDP receiver site C, it can send directly, without using UDP forwarder site B as an intermediary. If all is working, puddlehaven's site can send a UDP message to mine, and get back a response from my local or internal network-connected sensors.

On the other hand, if one wished to implement a "name-only" addressing scheme, not using the internet's DNS, a SimpleLan name server/message forwarder could be set up where a site publisher could supply the name, ip, and published functions (e.g., stelios, xx.xxx.xxx.x, 01=return outside temperature in Athens), and a user could send a message ("stelios", "01", "return ip address") and the forwarder could route the message using UDP, and even anonomize the requestor's ip by having the response routed back through it. I'm not altogether sure what advantage this conveys in what would, at least initially, be the small world of internet-published picaxe networks.
 
Last edited:
@Ibenson, regarding the following remark in this thread:

"I think my next step is to tie it to a Kranenborg-style network if I can figure out how to connect the 28X1 to that network as a self-powered node (the SimpleLan module seems to add over 100ma to the current draw--not quite as much as their documentation says). "


You can use exactly the same slave node circuit as described in the SerialPower document, just replace the back-up capacitor with the local power source

/Jurjen
 
kranenborg said:
You can use exactly the same slave node circuit as described in the SerialPower document, just replace the back-up capacitor with the local power source

/Jurjen
Click to expand...
I removed D5 too so the network interface is not trying to power the self-powered node.

Jurjen, is that correct?
 
Well, I was more thinking about Data Acquisition. Having all the sensors sending data messages in a central location can help you build up a database of information. Also, the central location will be able, based on triggers and data that it's receiving, to push messages to picaxe chips working as actuators.

So, for example, you have a small network of air temperature, ground temperature and moisture sensors in a green house. You also have a few PicAxe based actuators controlling the windows, fan, heating and watering. All these sensors push the data to your server machine. Based on that data and the trigger you defined, the server can also send messages to the actuators to start the fan or the heater, close the windows or open the water vane.

The same principle could be applied for a sensor network over a city. For example, weather probes 'feel' that is going to be cold and raining so the server sends out messages to you house to close the windows and start up the heating .

Of course, on the above scenarios you don't have a PicAxe-to-PicAxe communication.
 
You must log in or register to reply here.
Back
Top