"SerialPower" true two-wire data+power network

[kranenborg]

The Picaxe "SerialPower" Network combines power delivery and
bi-directional communications between processes on intelligent nodes
using just two interchangeable wires:



This network is based on two concepts:
- Networking hardware for linking Picaxe-based nodes
- Picaxe network software that implements communicating processes

A master node (Picaxe 08M/18X) provides for power as well as "timeslots" during which processes on nodes can exchange messages with each other using a standard format. The slave nodes are powered from the network and only need a backup capacitor. These nodes can be implemented using any available Picaxe type.

The concept of communicating processes is used (each process has a unique identifier), allowing abstraction from physical nodes and thereby flexible distribution of functionality over different nodes. A node may implement several processes, and the same process may run concurrently on several nodes with local modifications, as shown in the figure below (temperature reading process #11 adresses display process #2 which is distributed over two nodes);



The master node is completely application-independent, any process on a node can exchange information with any process on another node (including slave-slave comms). Message collissions are avoided by assigning each sending process a separate ID-marked timeslot. After network power-up, the master node automatically roams the network for processes that may want to send messages, and stores the corresponding process IDs for automatic timeslot generation later on. Furthermore, processes can register or remove timeslots for other processes on the fly as well.

A variant of the network software is also available for simple one-wire "diode-mixing" networks with separate power and serial communication lines.

In addition to the software, all details can be found in an architecture document at:
http://www.kranenborg.org/ee/picaxe/twowirenetwork.htm
Current version: v3.0 (April 2009)

Regards,
Jurjen Kranenborg

[Steve Joblin]

Very innovative idea! Excellent write up! Very much appreciated!

[kranenborg]

Hello,

I have significantly upgraded the functionality, software and documentation and it now (v2.0) supports the following:

• Fully automatic registration and provision of timeslots for up to 48 sending slave processes
• On-the-fly registration or removal of new timeslots (e.g because of some sensor condition or tripped switch)
• Plug & Play slave node support (including dynamic process ID assignment)
• Application of simple, "diode mixing" network hardware where separate power and communication lines are used.
• Support for Network Manager Node for automatic removal of unused timeslots and on-the-fly message CRC checking,
• User Guide for application programming

The link to the updated website is in the first post of this thread.


In more detail the updates imply the following:

Software (Network stacks for master and slave nodes)

Intelligent network-roaming master node + auto-registering slaves:

The master node now implements the following system processes:
- registerSendingprocess (request timeslots for a particular process)
- unRegisterSendingprocess (stop generating timeslots for a particular process)
- flashLEDmasterNode
It calls the following slave processes:
- roamSendingProcess (search network for sending processes; allow them to register in response)
- roamPlugNplayNode (allowing a plug & play node to get network access by registering extra timeslots)
- availableTimeSlot (make a timeslot available to a certain process, allowing it to send a message)
- configNetworkManager (if Network Manager node is in the system)

After power-up, the master node now automatically searches for potentially sending process IDs on the network (calling the "roamSendingProcess" process on slaves). The slave nodes *automatically* respond by registering timeslots for the IDs of any sending processes they implement (using "registerSendingProcess"). Consequently, the master node has become completely application independent and need not be reprogrammed for a new application, greatly simplifying application programming. All registered IDs are stored and managed in the 48-byte RAM memory of the PICAXE (all master node code still fits in a 08M!).

The master node now also has an indicator led that flashes very shortly whenever a slave node message has been received and decoded. Thus a simple but effective indicator of network activity is available. This indicator may also be addressed explicitly by any slave proceses using the above mentioned "flashLEDmasterNode" process with light duration as a parameter.

More advanced, big applications can now use sending slave processes that may request timeslots for other processes as well on the fly when needed (for example because of some switch being tripped or sensor reading) using the same registering process (and remove them with "unRegisterSendingProcess"), thus allowing dynamic network bandwidth management. This approach replaces an earlier track on timeslot prioritization.

Plug & Play slave nodes:

Building upon the previous "on the fly" registration of new sending processes, Plug & Play nodes can be attached to the network that subsequently register processes themselves. A hardware solution proposal for this node type is presented (open for improvement suggestions!), the master node software is adapted for continuous roaming of these special nodes. Furthermore, "dynamic allocation" of new, unused IDs to the new node processes is supported.

Hardware

Hardware interfaces for simple "diode-mixing" networks with separate power and communication lines

Simple "diode-mixing" networks like the ones proposed by for example hippy and Dr_Acula can be applied now as well with only minimal changes to the network stack software. Both a hardware description as well as software is available. Thus a protocol is available that allows bidirectional communications between any pair of processes on any node without message collisions.

Hardware for Plug & Play slave nodes is presented, which is supported by the new network software stack.

Documentation

• The documentation is updated with the above additions.
• A programming guide has been added for easy application development, including some examples.
• The code has been cleaned up and comments have been added extensively.

Future additions

"Network Manager" node (currently under development, picaxe-18x):
- This node shall remove unused timeslots after a while by sending a unregister command for the particular process (making explicit unregistering commands superfluous, resulting in much easier programming). This node acts as a slave to the master node and can be programmed from any node)
- The node also will remove unused dynamic process IDs, thus freeing up reserved IDs for other Plug & Play nodes that are added later.

CRC message checking (08M)
- calculates crc08 on messages and warns if errors are detected (by placing a message on the network)

High-speed HSERIN communications investigation for 28X1/40X1 based nodes
Both hardware and software need some small changes). Note that the current implementation already supports 28X1 and 40X1 slave nodes for standard SERIN/SEROUT comms.

With all of this implemented I think it is possible to rapidly prototype picaxe-based "ambient-intelligence" applications. Maybe this concept is also interesting for the lower layers of the Picaxe-SimpleLan development for global networking.

The master node software still fits (although just barely) in a 08M, a 08M slave node has sufficient room for applications.

I am interested in any comments and improvement suggestions, and I am particularly interested in suggestions for simplifications, for example for the Plug & Play node hardware, as well as the documentation. Furthermore I hope that some forum members are willing to test the ideas mentioned here using real applications.

I suggest to put all suggestions, questions and error reports in this particular thread.

Best regards,
Jurjen
http://www.kranenborg.org

[kranenborg]

A small error was found in all network stack files; errors are corrected and updated files are uploaded to the SerialPower website.

A few things to note that were not properly documented in the PDF:

The basic slave node network stacks have a dummy sending process. Since the master node LED flashes for each message that is sent by a slave on the network, a very simple test-setup is available that does not require extra hardware like a switch or the like; simply connect a slave and then power up the network.

I should also note that the master node LED lights up continuously during network roaming just after power-up, to indicate that the master node is busy registering sending slave processes. Subsequently the led flashes with each slave node message on the network.

/Jurjen

[kranenborg]

I should add another useful option that is not yet documented: adding a LED in series with the pullup resistor of the master node allows to see all master messages and interrupts, thus giving an indication of master node activity. This LED is shown in the red circle below:



The green circle LED indicates slave node activity, thus indicating that the slave nodes repond to master node timeslots. The combination of both LEDs gives a proof of proper network functioning.

/Jurjen

[kranenborg]

From some forum posts I get that there are at least a few that are implementing the SerialPower network (or plan to). I am particularly interested in comments from them (and others) on the three-page User Guide (Chapter 11, p50-52) of the V2.0 PDF document describing the network), because I think it is one of the most important parts. So my question is: is it a good guide for starting up, can it be improved, is something lacking?

Regards,
Jurjen

[puddlehaven]

Jurjen,

I've been playing with your ideas the last few days, but I'm afraid I'm nowhere near getting to the part where I get to use the User's Guide. I spent most of last weekend trying to figure out how the push-pull driver and the MOSFETs work together to drive the network.

The part I'm struggling to get my head around is how the processes cooperate with each other. For example, when I first started thinking about putting a temperature sensor on the network ('cause that's first all the time, right?) I couldn't figure out how to request the sensor read the temperature and then how the sensor would report back. I had a breakthrough when I realized that the sensor didn't need to be asked to read the temp, it just needed to report when a temperature had changed.

That's where I needed to make the logical leap, for what it's worth.

[puddlehaven]

Here are a few other things that I've noticed while I've been playing with Jurjen's Serial Power network:

• Beware the behavior changes when you're using interrupts
  
  If this is the first time you've used an interrupt driven program, you may be tripped up by the differences in the behavior that you get when your program is interrupted.
  
  For example, here's a common bit of code in one of my programs:
  
  

  Idle:
     TOGGLE indicatorLED
     PAUSE   500
  
     GOTO Idle

  This doesn't work like you'd expect because PAUSE is interruptable, and after the interrupt control returns to the next command (the GOTO). Because the network is regularly interrupting your program that PAUSE never runs to completion. In the default configuration the network interrupt period is defined as equal to t_comms, which is every 52ms.

• t_startup_masterNode needs to be longer than your longest slave node's start up time, or your slaves have to be ready before t_startup_masterNode expires.
  
  I have a serial LCD backpack that needs a 5 second delay between power up and when you start throwing data at it. With the default 2 second master node start up time roamSendingProcess misses the LCD node. I needed to come up with a way around this, in my case setting the master node start up time to 10 seconds. There is a more elegant way that I haven't implemented yet, registering a node callback process during network roaming and then dropping off the network to do node startup tasks, then re-synchronizing and registering processes once the node is ready.

• Be sure to de-synchronize from the network before doing time-sensitive tasks.
  
  This goes along with the previous point. Jurjen points this out in the docs but it bears repeating. If you find yourself needing to control the timing of processing, you need to de-synchronize to turn off interrupts before you start your long task. That serial LCD backpack needs 200ms between calls that write to EEPROM. If you use PAUSE 200 between your calls you really only get 52ms and your LCD gets funny...

• Process ID 10 ($0A) does not get registered by the network roaming process in certain circumstances.
  
  I think this is a bug in the network stack that is obscured by the way the network stack and sample code are written. There are two changes you need to make to the network stack to see this:
  1. In the master node code, comment out the configureNetworkManagerNode subroutine and the GOSUB to the subroutine.
  2. In the slave node code, change IDuserDefinedSendingProcess to 10.
  
  Here's what I think is happening:
  
  1. The network is powered up. The slave node finishes initializing and uses the reSynch subroutine to sync up with the network. It stays in the reSynch subroutine waiting for network activity.
  2. The master node starts roaming for sending processes. It starts by asking process ID 10 to respond.
  3. The slave node sees the network activity and syncs to the network.
  4. The master node doesn't get a response from process ID 10 and moves on to ID 11.
  
  The code from the Web site either calls configureNetworkManagerNode which enables the slave to sync before the master starts to roam the network, or has IDuserDefinedSendingProcess set to 11, which enables the slave to sync when ID 10 is queried.
  
  I was able to work around this (without changing the IDuserDefinedSendingProcess value) by adding an extra network access to the roamForSendingProcesses subroutine. This extra request gives the slave nodes something to synchronize to so they are prepared to listen for the master.
  
  

  roamForSendingProcesses:
     IDdestinationProcess = IDnoProcess
     GOSUB createTimeSlot
  
     ... rest of code unchanged

Thanks for taking the time to read this rather lengthy post...

Chuck

[kranenborg]

Hello Chuck!

I am most grateful for your clear and very useful remarks. I do not have the time right now for a detailed answer and document update, but your remarks make very much sense and in the weekend I will formulate an answer and a document update based on your input (and other contributions that may show up this week)

One remark for now, concerning the registration of process ID = 10. In your explanation you write on the function of the resynchronization function that " It [the slave node after start-up] stays in the reSynch subroutine waiting for network activity". That is not how it should work; the reSynch routine should wait for a defined period to see if there is some network activity, and if there is no activity after this period (i.e. it is continuously high) it should enable interrupts and exit (and thus the "dummy" network slot that you use should not be necessary) . The period is currently equal to t_byte, but should actually be slightly longer. Furthermore according to the count command definition the "rises" register should be a word register, so it looks like you found a fault here altough I am not sure that this explains the behaviour you reported. As said, i will look into this deeper this weekend.

What is actually the application you are developing? I intend to include applications (or links) in order to support application development. I also have the impression that your master node is not a 08M ...

Best regards,
Jurjen

[puddlehaven]

It looks like I made a tiny little error...

Up until last night I haven't actually had a 2-wire master that would actually run, so I've been playing with a 3-wire diode mixed-setup, like your figure 11.

Under that figure it says "The polarity of the SEROUT message in the availableTimeSlot routine should be reversed" so I did, but then becuaseof my setup, I ended up with the whole network running using TRUE logic (T2400), which means the network was low in the idle state instead of high. That explains why the reSynch subroutine was waiting for the first transmission from the master before it returned.

I am using an 08M for my master node, however I just got your hardware for the master node up and running. It took me about 4 hours of troubleshooting last night to figure out that I had the drain on T4 connected to +5V instead of the output. I only have an 18X for a slave node, but it's simple enough to modify your 08M code for the 18X.

Right now this is a solution in search of a problem. Just getting a network up and running is a challenge in and of itself, and right now I'm enjoying that process. Once I figure out the network, I'll add some nodes for specific purposes. Right now I'm planning an environmental sensor node (we all have DS1820s, right?), a display and control node (LCD, keyboard, clock), a motion control node (servos), a switching node (relays), and a PC interface node.

I should have several enjoyable months of figuring out how to make all those nodes work. After that I think there's some interesting work I can do with combining "sensors," nodes that put information on the network, and "actors," nodes that take information off the network and do things with it.