"SerialPower" true two-wire data+power network


Senior Member
Hello Rodney and other interested forum members,

Here is information on the beta test versions of SerialPower II, now with test codes for both M2 and X2 (a system may combine them both).

The test system that I propose (and have used succesfully with the M2 picaxes) is as follows:

The only change that I made regarding to the previous setup was to have the network input / output pin identical, which saves particularly on a 08M2

Here follow the test codes for M2 and X2 respectively all appliccable to the above circuit. The M2 codes function perfectly at my prototype, but I do not have any X2 to test so I would appreciate if people who do possess one or more X2 processors could test the X2 codes as well:

M2 master and slave codes (here for 18M2 master and 08M2 slave):

X2 master and slave codes (here for 20X2 master and 20X2 slave):

The codes can be used for other M2 and X2 variants as well as for different input/output pins. In the latter case, a change of input pin should also be reflected in the interrupt mask! The X1 variants could not be implemented since these do not have the required bidirectional flexibility for serial operations.

I would be really thankful if those who test could report their outcome here.

Note that there are some slight code differences between the M2 and X2 variants, all because of the fact that the RAM areas for getting and storing messages are different; the X2 variants use the scratchpad area whilst the M2 use regular RAM. This means in practice that when accessing the RAM message areas the following conditions hold:
- M2: use PEEK and POKE to access the message RAM areas and use the bptr pointer where relevant
- X2: use GET and PUT to access the message RAM areas and use the ptr pointer where relevant
The differences become clear when comparing files with a tool like WinMerge etc.

The output to be expected is described in item #37 but repeated here for completeness:

Thanks, and let me know your experiences!
Last edited:


Senior Member
Hi Jurjen,

I have followed your progress of this project over time, but alas do not have a purpose for it myself. :)

In the above overview drawing I ote that you shw a 3-wire sustem. Have you indeed changed the system somewheat, or have I missed an announcement?



Senior Member
Hello MPep,

I did not change the bus system and SerialPower II will support both the combined power/serial data solution (2 wires) as well as the more simple three wire system ("diode-mixing network") as shown above. Examples of both of these solutions are shown in item #26 of this thread. However for software testing purposes of the current beta release I decided to focus on the simpler three wire system first, in order to make it easy for both myself and others to build a minimal system for testing. As soon as I have confirmation about the X2 variant of the software working well I will start testing the case for the true two-wire network solution (I have changed the protocol for that case such that power can be delivered by the master node at short intervals * during * slave message transmission (allowing the slave backup capacitors to be much smaller) , and that needs some proper testing!). Remember: SerialPower combines two - fully independent - concepts that thus can be applied independently as well: 1) network hardware for power + data over 2 lines and 2) a software protocol for implementing a fully distributed processing picaxe system in which the message handling is done automatically.


PS: For an example of a simple application of the full two-wire version of the original SerialPower protocol by someone else (very well documented!) have a look at Chuck's website: http://www.bramblyhill.com/page/SerialPower-network.aspx
Last edited:
Jurjen (and all),

{Update: The changes in this post aren't necessary -- see the comments below in #47. I'm leaving it here though so I don't break the flow of the conversation.}

It's good to see an update to this network stack. I've been interested in how you were going to change the stack to take advantage of the more powerful chips available now. I like the changes that you made, especially the ability to send variable length messages -- it solves the problem of trying to send lots of bytes with only two bytes of data payload.

I got the simple diode-mixing network running using an 18M2 as the master node and a 20X2 as the slave node. There were a couple of issues in the programs that I downloaded (from the links in Jurjen's post of 8/10/2011, last downloaded on 12 October 2011). I put a lot of debugging SERTXD statements in, and changed a lot of the timings to allow time for the SERTXD statements to run, but once I had the 18M2 and 20X2 talking to each other I backed out all of my changes until I had the two updates required to get the sample code to run.

The first is fairly easy to fix. In the Master Node program, the delay between sending a command to the slave nodes and turning off the master node interrupts needs to be lengthened. This line needs to be changed:

   REM Now sit and wait (unless interrupted) for a while to implement the timeslot 
   PAUSE t_INTslave
to this:

   REM Now sit and wait (unless interrupted) for a while to implement the timeslot 
   PAUSE t_slaveTimeSlot
So much for the simple part of the fix. The second issue has to do with serial baud rates and the clock frequency of the nodes. The X2 parts have a base clock frequency of 8Mhz, the first instruction in the slave node program is SETFREQ M4, which cuts the X2 clock frequency in half and messes up the baud rate constants. Later, in the network configuration process, a SETFREQ M32 instruction is executed (the master node changes the network clock frequency on start up) and the baud rate constants are messed up again.

I found that by changing all of the baud rate constants to the frequency specific constants (M4, N4800_4, T4800_4) I could get the nodes to talk to one another. But that meant that the clock frequency of network nodes was fixed and couldn't be changed by the master node. To get around this, I created two new variables, NbaudRate and TbaudRate. I use these in the network configuration process like this:

   SELECT dataByteH
          NbaudRate = N4800_8
          TbaudRate = T4800_8
          SETFREQ m8
          NbaudRate = N4800_16
          TbaudRate = T4800_16
          SETFREQ m16
          NbaudRate = N4800_32
          TbaudRate = T4800_32
          SETFREQ m32
          NbaudRate = N4800_4
          TbaudRate = T4800_4
          SETFREQ m4
and in the body of the code I replaced all of the T4800 baud rate constants with TbaudRate, and all of the N4800 baud rate constants with NbaudRate. I made a similar change in the master node code, updating the baud rate variables just before setting issuing the SETFREQ M32 instruction.

With those issues dealt with, the sample program is up and running on my desktop. Copies of the code for the master and slave are attached.
Last edited:


Senior Member
Hello Chuck (aka Puddlehaven)

Many thanks for your testing efforts! Your results suggest to me two things (given the fact that the original code runs without your adjustments on a M2 system):

1. Some timing constants as defined in the stack may be too tight and need to be relaxed (as revealed by your first point):

Your investigations reveal that t_INTslave is just barely long enough for the slave interrupt handlers to react on a timeslot availability message from the master and subsequently use the timeslot by sending the slave message, and in your 20X2 system it seems to be too short (whereas on my M2 system it is still right) , so indeed this time period needs to be lengthened. It should not be too long either (at 4MHz, t_INTslave = 8ms but t_INTslaveTimeSlot = 30ms), because in the time period that the master is waiting for a slave message the network is not actively powered (only the pullup resistor is active) and a long waiting period would then remove the advantage of the changes I intend to make to the two-wire variant of the protocol to allow active power provision during slave message transfer (I will later explain this feature, it still has to be properly programmed and tested). Could your therefore test for me whether replacing t_INTslave (4 ms) with t_dataFrame (14 ms) instead is sufficient to resolve the problem (it should in my opinion)?

2. I get the impression that the 20X2 that you use may need its clock frequency calibrated (I alreay envisaged a calibration procedure to be included in the final release, as written earlier):

Your test has shown that the differences in base frequencies for the picaxes may lead to problems and I am very glad that you found it and provided for a mitigation (that must have taken some hours?). I had not thought of this issue myself. I think that replacing 4800 with 4800_4 in the original code should be sufficient (your first step), even for running at higher freqs (and it does for the M2 version!). The reason is that for one-byte serial transfers the increase in MHz should not lead to problems for the SERIN/SEROUT to handle the upscaled serial bitrates (it does for more databytes per serin/serout command, as noted earlier on this forum). The main motivation for me to allow higher freqs was higher bitrates. (Note that the SERIN command explanation in the manual also shows that bitrates scaled with frequency are possible, I get from it that 4800_4 = 9600_8 = 19200_16 = 38400_32)

Could you test my 4800_4 suggestion in your case as well ? (you can also change all your baudrate constants to ****_4 in your code to get the same effect). The solution that you provide for right now would not profit from a higher baudrate at higher clock frequency. If my proposal doesn't work then the problem must be related to the 20X2 clockfrequency being too far off. I do remember that I have looked into the PIC18F14K22 datasheet a while ago and noted that early silicon releases of this chip have a much larger margin on clock frequency than usual. The automatic frequency calibration I have planned to include for the final release will resolve that issue though.

So what are the next steps that I have planned in order to get at the final release:
1. Implement a procedure for automatic frequency calibration at network start-up to increase the communication stability, particularly at higher clock freqs.
2. [NEW] Dynamic network bandwidth management: Include a possibility for automatic removal of timeslot generation for those sending processes that do not use their timeslots (and thus clog up the network unnecessarily). After a number of consecutive unused slots (a number that can be specified for each process separately during registration) the corresponding process ID will be removed from the master node's ID table used for timeslot generation (but it can be added on the fly by another process later on). This is something that I had in mind already (and partially programmed) for the previous SerialPower implementation using a separate network manager picaxe (18X) but the increased RAM memory size in the 14M2 and 20M2 make this possible in those master nodes without extra cost. As a consequence it is possible to fork a number of processes under certain useful conditions (sensor readings etc.) and let them then "die off silently " whenever they are not needed anymore, avoiding the need for complex de-registration (using the unRegisterSendingProcess, although it can still be done for maximum bandwidth efficiency). Consequently a large number of processes can be handled efficiently as well and this widens the application area without the need for going towards 16-bit IDs (which is much more complex regarding ID registration).
4. Upgrade the documentation.

I really appreciate the effort that you all are putting in testing this, and as a consequence we are getting towards a very nice and advanced implementation. Are there other useful functions that could/should be added to the stack as a standard (like I did with the "constructStringMessage" helper routine and the sendStringSERTXD process, for example) ?

BR, Jurjen

PS, I will not remove the old SerialPower V3 version and documentation, since the older chips will be around for quite a while.
Last edited:
No problems Jurjen. Testing is the easy part -- all I have to do is find problems. Coming up with the ideas in the first place is the hard part.

Anyway. The fix that I offered above turns out to be more complicated than it needs to be. The only change that you need to make is to update the 20X2 slave code by replacing "[T|N]4800" with "[T|N]4800_4". With that single change the two nodes (18M2 master and 20X2 slave) can communicate just fine -- I didn't need to change the length of the slave time slot after all, and the 18M2 master node works fine as is.

With that in mind, I decided to test the minimum length that the slave time slot can be. The slave can interrupt the master node with the slave time slot set as low as 5ms.

One issue with the 20X2 code is that changing to to 4Mhz operation doubles the length of all of the pauses in the program -- a 14 ms pause in the standard code becomes a 28ms pause when the 20X2 is running at 4Mhz. I guess the next tests that I need to run are about how the X2 parts interact with the changing network speeds -- it occurs to me that running at the natural base frequency of the X2 parts is one of the advantages of using those types.

I don't have any suggestions for utility subroutines right now. The only thing that I can think of is to update the "reSynch" subroutine to make sure that the processor is running at the network frequency before it reconnects -- since the master node sets the network speed it isn't possible to know when the slave code is written what frequency is necessary for connecting. For example, the SERVOPOS instruction requires specific processor frequencies, so I need to deSynch from the network, set the frequency, then run the SERVOPOS instruction, then reSynch to the network without necessarily knowing what the network frequency is.



Senior Member
Hello Chuck,

Very short reaction for this moment as i am in a hurry for finishing some work-related stuff.

1. The X2 base frequency of 8MHz:
I realize that you raise an important observation here: "it occurs to me that running at the natural base frequency of the X2 parts is one of the advantages of using those types". This would then mean that the best solution would be to aim at the same base freqs (and consequently same timing) for all of the nodes, instead of the same frequencies. That would I guess solve all (or most) problems since the SerialPower protocol depends on a common agreement on timings.
As a consequence we should define "Base", "Base_x_2", "Base_x_4" and "Base_x_8" freqs instead of actual freqs, and then these frequencies are set differently for M2 and X2 (4-32Mhz and 8-64MHz respectively). Also, the X2 baudrate constants should then be 4800_8 whereas the M2 baudrates become 4800_4.

This should all be tested, but I expect that the base frequency approach you suggested it will actually work and is easy to implement with just the alterations as described.

2. Regarding the issue with reSynch and restoring to the network frequency (base, base_x_2 or base_x_4):
You are right with this issue as well. A solution woudl be to store the network frequency for a given node in a memory location, such that reSynch can restore the proper network frequency from it. That will be an easy fix as well.

I'll update the codes asap, thanks for your remarks

BR /Jurjen
Last edited:


Senior Member

I have updated the M2 and X2 codes in the links of item #42 above, with the following enhancements:

1: Network frequencies implemented (Base, Basex2 etc.) according to puddlehaven's recommendations, taking into account the differences in base frequencies for M2 (4 Mhz) and X2 (8 Mhz) such that the network timings will be correct.

2: reSynch includes restoration of network frequency according to puddlehaven's recommendations

3: A routine called "ApplyNetworkFrequency" has been added which sets the proper node frequencies as discussed in points 1 and 2. Furthermore this routine sets a variable called "RAMtimeConstant_1000ms" which - when applied on a pause command - gives a 1000 ms (1s) pause, irrespective of the network frequency or node type (M2 or X2). In this way frequency-independent timing constants or factors can be derived.

The M2 variant runs properly on my system with the new code, tested with differemt frequencies, it would be nice if someone could check the X2 variant as well.

Jurjen Kranenborg
Up there in #43 MPep commented " don't have a use for it." In the interest of sparking ideas for the use of Jurjen's Serial Power Network, let me present the "research network" that I'm using at home.

My research network consists of an 18M2 master node and a 20X2 slave node for the Serial Power V.II network scheme. I'm using it to test and validate that the code that Jurjen wrote works as he intended on hardware that he doesn't have access to. I've also got a 5-node Serial Power V.I network set up -- there is a master node, two sensor nodes, a display node and a control node. The 20X2 is connected to both networks, but I haven't started working on the bridge software yet.

All on a standard 2390 tie-point breadboard.

Great, you say. But what can I actually do? Here's what I can simulate on my desktop:
  • Networking fundamentals, including bridging and routing.
  • Distributed and shared computing using microcontrollers.
  • Sensor network for near-space balloons or model rocketry.
  • A heating and cooling control system.
  • Control system for model railroads.

With a little bit of imagination you can create a test-bed for just about anything.



I tested the latest version of the 18M2 master and 20X2 slave code on my test rig. It works great.

Thanks for the changes that you made, it's looking good.


Senior Member
I have not yet thought in detail about applications since my primary goal of developing SerialPower was an architecture investigation on how far I would come with a highly automated distibuted microcontroller system using a Picaxe.

However some application areas have crossed my mind, in addition to those mentioned by puddlehaven:

1. Wearable electronics:

This is a developing field in which the Arduino Lilypad is popular, but I think that SerialPower could be particularly useful here. See the following links for Leah Buechley's work as well as Sparkfun's material developed for the Lilypad:

http://web.media.mit.edu/~leah/LilyPad/ (Leah's project website)
http://www.sparkfun.com/categories/204 (the main Lilypad products)

In particular the LilyPad protoboard ( http://www.sparkfun.com/products/10515 ) and conductive ribbon ( http://www.sparkfun.com/products/10172 , note that is has three conductors and thus would allow simple diode mixing) could be very useful

2. Lego:

This is an area where particular the true two-wire variant (unpolarized) would shine. See Michael Gasperi's site ( http://www.extremenxt.com/lego.htm ), as an example one of the links there show how the lego bricks can be adapted to have added two conductors: http://www.stormyprods.com/lego/

3: Christmas!

Well, putting all kind of funny stuff in a christmas tree is not my cup of tea, but with some imagination some nice things could be done there (touch-sensitive angels, rocking-sensitive boats and even a capacitive-sensing based christmas ball that alter the behaviour of the tree lighting :eek:)

4: Any project that includes a lot of wires (the model railroad example was already mentioned, but also robots, alarm systems, etc. can be thought of) could be much simplified with a SerialPower implementation (for example the airport model that my son and I made would have avoided the terrible wiring complexity it has right now: http://www.kranenborg.org/electronics/37-ir-controlled-airport-model ).

5: More advanced facilities like floating-point calculations or data storage can be made available to all nodes in a network, by implementing such a facility in a node and then defining a process to access it.

6: Of course I would have loved to have SerialPower as the backbone of imaginative and advanced art projects like the "Silent Barrage" project as described by inglewoodpete here: http://www.picaxeforum.co.uk/showthread.php?17286-PICAXE-Network-on-show-in-Dublin&highlight=neurons

7: Many network solutions that now have a single point of information / control would get much more flexible in use when having several of those points (each having the same process software, but with a different ID)

When starting to think of applications it is useful to realize that what is called the SerialPower master node is only a master regarding SerialPower's network communication protocol; an application master would normally be located at a slave node and I would recommend to keep the SerialPower master node application-independent and let it just do what it is supposed to do: deliver power and generate timeslots in a "democratic" way ... .

Starting now with the next step towards the final release: automatic frequency calibration at network startup

Last edited:


New Member

Firstly, apologies to Jurjen for my not yet having tried V4.

Secondly, Chuck seems to be steaming along as chief tester (and fix suggester!) - great work, I'm learning a lot from it.

Thirdly, I'm very interested to see the matter of potential applications get an airing.
My particular interest is model railway(railroad) control systems.
THere's a long-established society in that area: MERG (Model Electronic Railway Group www.merg.org.uk).
I happen to be the editor of its quarterly Journal.
We have quite a few members working on what we call the "Layout Control Bus" area.
There are some implemetations already up and running but most of the hardware designs so far has been based
on using the CAN (Controller Area Network) physical layers using CAN-capable PICs and assembler language.
Running some of our already-developed higher layers over different lower layers and hardware is of interest
to me and Jurjen's Serial Power V4 with multi-byte messaging support seems to potentially offer an excellent basis for
implementing a lower speed, lower cost, BASIC-programmed but compatible alternative to our existing platforms.

Regards, Rodney


Senior Member
Hello Rodney,

No problem that you haven't been testing yet, SerialPower II appears to be in quite a good shape (although Chuck only has one 20X2 and uses it as a slave, maybe you could still test a 2 x 20X2 system so that we know that a full X2 system works perfectly as well?)

In post #29 you wrote:

" If your existing byte-wise S.P. msg format:
[message ID] [node ID] [data byte] [data byte]
grew in S.P.4. to at least:
[[message ID]] [[node ID]] [data byte] [data byte] ... [data byte]
where [[..]] indicates 2 bytes,
there would ensue a really neat mapping of our messaging! "

With SerialPower II as I see it we are quite close to that frame format, with the 16-bit message ID's as the main challenge left.
Although theoretically 16 bit ID's could be used as easy as 8-bit IDs in the current implementation (the M2 and X2 have enough RAM to accomodate for the storage and handling of 16-bit IDs, and only those IDs that are actually needed are stored), the main problem that would arise is the excessively long time that is then needed in order to roam for all 65536 possible IDs (at 32MHz would approximate 256 x 5 secs = 21 mins) that potentially need to get registered with the master ndoe at start-up.

However, if I understand your explanation in post #29 well, the 16-bit IDs consists of a segment number byte and a node number byte, right? If then a segment controller could take care of providing the ID numbers of the nodes that it manages, then I could envisage a "layered" ID registration protocol (remember: only needed for sending node processes) that could be roughly described in metacode as follows, and would not be very complex to implement:

DO for all segment numbers (ID 10 - 254)

Step 1:
- ask for each segment number how many series of node registration commands will follow (multiple series may be needed if more than 32 IDs for the currrent segment are to be registered as sending processes, due to the 32-byte message size limit)

Step 2:
   DO for each series (node registration command as sent by segment slave node)
       DO for each node ID in the given series
            register ID = [current segment ID byte, node ID byte]

Does the above procedure seem reasonable, or have I misunderstood the protocol format that you use?

I estimate to need approx 2-3 weeks to finish the last details of SerialPower II and to release is as a proper version, and would then be very interested to start implementing the 16-bit ID case as I think of your application to be very interesting and with the MERG seem to have a large group of technically capable people backing it.

Let me know your thoughts about my suggested solution direction
Best regards,

--> PS: I now see that I have misunderstood your protocol somewhat. I will send you a PM so that we can discuss offline
Last edited:


Senior Member
Dear forum members
A small status update: All M2 and X2 codes work well for diode-mixing networks (i.e. separate power and comms lines) but I still have a problem with the two-wire power+data network: I cannot obtain the same comm speeds as the older version of SerialPower on the same hardware, so there must be a timing problem. I am going to order womai's dpscope to help me out (I have only a multimeter as my most advanced electronics tool) since I want to launch SerialPower II very soon now, including documentation



Senior Member
@Jurjen, Ray did ask for you in his initial post. Your input would be of interest. The posts were moved because the subject matter was an for application which was thought might be a candidate for your system, but not directly related to your development project.

Follow the link in the previous post where we are attempting to draw a picture of the requirements.



New Member
Hi, Just found this thread! Looks promising for an application I am concerned with.
Myself and a friend are starting to think about a new signalling system for a miniature railway (7.25" and 5" gauge). It has 20 electrically controlled points spread over 200m.

Has anyone had any experience with a SerialPower network outside and with cable runs this long?


New Member
Hey guys i am working on a project called use of twin wire power lines for data transmission, in which two 'live wires' will carry common mode voltage and DATA is sent as a differential voltage between these two wires and the third wire being a ground.

I am pretty sure that i will be using an instrumentation amplifier to seperate my data at the recieving end.

But the issue i have is at the transmitting end because i am not clear what should be used to combine POWER and DATA.

So, i need your precious suggestion guys. Please help me.
Thank you.


Senior Member
This project SerialPowerII is interesting.
What is the current status? Any introductional / overwiew / principles document?
Yes i am lazy if i can ;)

There are many variants on this subject
I once designed a simple power+comms twisted pair master-slave type. The main node supply current limited and regulated voltage. When the remote node had something to say (after performed cyclic measurements), it shortly shorted the power, master detected and switched to serial receive, remote send start byte, data, CRC and go into receive, main node transmit a similar package back and then apply power. Full cycle about 20Hz. There were some EMI but passed OK. Distance was only 7 meters.

Currently I am thinking on a future project where the idea of three wires like in post #60 could be feasible. I would chose the single wire as 60 volt DC, (I need a couple hundred watts through a couple hundred meters cable) and the comms pair to be GND. I think that would make less noise in signals, and i will have two GND which feels better. Yes current balanced transformer coupled i think is the way to do it. And impedance matching... The current prototype use cat5 ethernet cable for RS422 and separate power but i would like to use thinner cabling.


Well-known member
You should be asking this question in its own thread if it has little to do with this thread. Makes life easier.

There are many variants on this subject
I once designed a simple power+comms twisted pair master-slave type. The main node supply current limited and regulated voltage. When the remote node had something to say (after performed cyclic measurements), it shortly shorted the power, master detected and switched to serial receive, remote send start byte, data, CRC and go into receive, main node transmit a similar package back and then apply power. Full cycle about 20Hz. There were some EMI but passed OK. Distance was only 7 meters.

Currently I am thinking on a future project where the idea of three wires like in post #60 could be feasible. I would chose the single wire as 60 volt DC, (I need a couple hundred watts through a couple hundred meters cable) and the comms pair to be GND. I think that would make less noise in signals, and i will have two GND which feels better. Yes current balanced transformer coupled i think is the way to do it. And impedance matching... The current prototype use cat5 ethernet cable for RS422 and separate power but i would like to use thinner cabling.


Senior Member
What you quoted was not meant a question, just a couple side notes on the subject and earlier side track. Maybe i rant too much.

About the SerialPowerII design i wanted to know if there exist some target/principles documented, or if all is in the implementation (basic code).


Senior Member
Jurgen hasn't posted here for over two years and his web site says "Version 3.0 (April 2009)", not sure what that refers to.

I think SerialPower has died.


Senior Member
Hello Morgan,

Sorry for this delay in replying (And I just recently noted the PM). Indeed, you have found the documentation links to the SerialPower concept (it is also the link in the first post of this thread). I am in the process of moving to a new country/house/work environment which will happen this summer so my priorities are elsewhere for the moment, but I'll be back since I intend to work with the picaxe in the future as well ... . My website on electronics contains all material that I have. I do intend to revisit the SerialPower concept but that will be on a longer term.

Best regards,
Last edited:


Senior Member
Thank you Jurjen
No hurry I am just "theoretically interested"
I wish you luck with your move
(...and i complain about just tidying my workshop...)


New Member
I wouldn't mind getting my hands on some kind of schematic for this. There is a product on the market that incorporates a master and several slave devices which run on a 2 wire system, polarity doesn't matter. Carries both data and power. Only the master carries a battery. The slaves are addressable via 2 buttons, up and down 0 to 99. Displayed on a 2 digit LCD display which still operates for a lengthy period of time after power has been removed. the slave unit uses a super cap on the 5v supply line.


New Member
Super interesting, where is the wright place to get the software? no body says nothing about software, any direct link to get the software.
Thanks for any help on this


Senior Member
SerialPower I V4.0 released (September 2018)!
This means:
  • Full re-implementation of earlier code on modern Picaxes (M2 for Master Node + any mix of M2 and X2 for Slave Nodes). All codes were tested on a true two-wire network. Code documentation has been strongly rewritten to improve clarity in programming (User Programmable Areas).
  • Fixed 4-byte messages (2 data bytes).
  • Re-designed electrical circuits (see SerialPower: updated implementation for M2/X2 Picaxes) after extensive testing, resulting in much higher network stability.
  • Speed of operation of all nodes (Picaxe clock frequency) programmable at master node (min 250KHz, max 32MHz for M2 nodes).
  • Proper base for development of SerialPower II (whith variable-length messages (1-32 data bytes) and more functionality.
See the first entry (#1) of this thread for all info and link (which is given here as well: SerialPower I V4.0). Any discussion on possibilities, trials etc. most welcome here in this thread!

Important note: SerialPower I will be maintained and supported in parallel with future releases of SerialPower II (as a simpler, less resource-intensive variant)!

Best regards,
Last edited:


Senior Member
Documentation of SerialPower I v4.0 finished, including website with all links functional and informative (documenting properly takes a *lot* of time even with seemingly small changes): SerialPower Home. Suggestions for improvements, corrections etc. on website, architecture document etc. are most welcome!
Full focus now on SerialPower II
Last edited:


Senior Member
I am happy to inform that now (besides SerialPower I -V4.0) SerialPower II is fully functional and available for download & use. The first item in this thread has been updated and contains the main link: SerialPower I & II. There, all info on its software and hardware implementation is available.

SerialPower II allows variable message sizes (1 - 32 bytes) according to the following format (a user application need not worry about the message descriptor, it is managed by the SeriaPower II Network Stack) :

Furthermore, in its most advanced version on a plain two-wire network, it interleaves power and datatransfer for each byte of the (slave node) message, thus allowing slave nodes with small capacitors which only lightly load the network:

More info on that can be found in the following hardware-related sub-page of the SerialPower home page: https://www.kranenborg.org/ee/picaxe/SerialPower/SerialPower_Hardware.htm

Comments & improvement suggestions on documentation, programs and functionality - as well as info on applications - are most welcome!

Jurjen Kranenborg
Last edited:


Senior Member
Thanks for the update Jurjen. I was intrigued by your concept when you first posted it all those years ago. I am thinking of creating a "universal" slave PCB so that I can create a small network capable of digital I/O, PWM and ADC. The simplicity of using just a light twin flex for comunication and power is a great idea.


Senior Member
Cool! Let me know if you need support in any way. And I am most interested in your development steps (and of cousre in the applications you foresee), as these steps may highlight issues and inspire for new ideas & applications. The Architecture Document on the SerialPower website has been updated for SerialPower I in 2018 and needs an upgrade to SerialPower II, but I already made the upgrade notes for it this year, so I have some homework these weeks :cool:.

Last edited: