SerialPower: updated implementation for M2/X2 picaxes


Senior Member

Some of you may remember my SerialPower network software that I developed for the older M/X Picaxe chips variants. I delivered a fully functional SerialPower 1 version (V3.0) for those older chips that is documented in detail in the following thread, located in the Finished User Picaxe projects / Communication section of this forum: This protocol allows a data packet of two bytes to be transmitted over a mutidrop-network that may consist of two simple wires (data & power combined) or using a three-wire diode-mixing setup. The site at the link explains it all.

I have again taken up the challenge of delivering a fully working and documented SerialPower II version (faster & allowing flexible-length messages of 2 - 32 bytes), since this activity came very far but stalled several years ago. Its development was described in the same thread as well. I am not there yet, but as part of this renewed activity - requiring me to build and test a new hardware test platform - I decided to first reimplement the original SerialPower I version (now becoming v4.0) on this platform so that it is suitable for the modern M2/X2 Picaxe chips. Added bonus is that the higher clock frequencies (max 32Mhz for M2 as compared to 8Mhz for the M-chips) are available for higher performance. The reimplemented code has also been reorganized for better comprehension and flexibility. The code is heavily documented.

I have not yet adapted the online-documentation for SerialPower 1 v4.0 nor can I make a statement regarding the delivery time for the new final tested SerialPower II and its architecture description. But the train is running at full speed now seemingly in the right direction and it is fun! Also, it re-introduces me to the Picaxe and this forum which feels very good.

Further technical discussions will follow in the thread mentioned above, this is only a statement to advertise my new commitment on this subject.

Enjoy your holidays!
Jurjen Kranenborg
Last edited:


Senior Member
A small change to the documented Master and Slave node circuit is needed, as indicated in red in the following diagrams


The combined changes have a dramatic effect on the stability of the network when operating at higher frequencies (analysis was possible thanks to Womai's DPScope, by the way ...)
Last edited:


Senior Member
DPScope still going strong ;=) Need to mention every now and then that the Picaxe brought me into microcontroller programming - and as a consequence, developing microcontroller based oscilloscopes (first one was actually based on a Picaxe)
Last edited:
Hello Jurjen,

I am very pleased that you have your SerialPower development under way again.
I hope it goes well and I hope to get aboard in a practical way this time round, in due course.

Best regards,

Rodney Hills

Surrey, UK


Senior Member
Hi Rodney, thanks for your interest. For SerialPower I V4.0 (i.e. the original 4-byte message frame with 2 databytes but now for M2/X2 instead of the older M/X chips) I am currently updating the manual and validating the code for X2 master and slaves, as I only wish to release tested software on a dependable hardware implementation (with consequences already for the original V3.1 hardware as shown in post #2).

When that all is done I will publish everything and then move on to SerialPower II development (for which the hardware improvements may show to be the key to the problems I had with it ...)


Well-known member
Howdy, Jurjen! I've been following your project from the old days and was disappointed that development stopped from my perspective.

My local application just naturally evolved from wired nodes to wireless nodes, so there is that question to you.

Ignoring a significant development in your design, the two-wire distributed power, how can you imagine the communications between nodes working with wireless connections (and local power.)

I'm currently working with the robust HC-12 RF modules, but there will, of course, be hardware upgrades over time. (I've never been able to develop as fast as the hardware! :D )


Senior Member
@tex: Regarding work opportunities, my move back to my home country NL from S took more time and energy than expected, however the situation changed drastically for the good a few months ago (will be involved in the semiconductor lithography industry actually), so now is the time to channel some of the freed energy towards SerialPower (which never failed to challenge me regarding future opportunities).

Regarding the analog behavior of the SerialPower circuits: In the attachments an example is shown for the slave node of the input signal that the slave Picaxe sees. It appears that the reverse capacitance of the BAT85 Schottky diodes is such that there is a delay in the signal going low at the slave Picaxe side when the master node transmits a low logic level. The two pictures show the effect of changing the mass grounding resistor from 220k in the V3.1 circuit to 68k in the V4.0 slave circuit as depicted in post #2 (at the expense of slightly higher loading of course). This change was one of a few that were necessary to allow 32MHz operations. Until very recently I had the opinion I could do without a scope, but those days are gone ...

Last edited:


Well-known member
Jurjen, that is good that you can upgrade your network hardware to operate at a higher network speed. Some applications could benefit from that optimization. However, maximizing network throughput is not very high on the list for an operation that networks battery cell charging. Slow might even be preferred for many reasons.

I, and others, are more interested in a robust network connection with error detection.

Can you imagine your software communication system working without the hard-wired network?


Senior Member
@ Tex: will address your question very soon (Short answer, yes I do think so, but discussion needed)

As a showcase of how important/unavoidable analog behaviour is in a digital world ... :

I was quite close to rolling out SerialPower I v4.0 since the documentation has been upgraded and most configurations tested, then discovered that the concept likely has worked until now only because of sheer luck and out-of-spec behavior of the PICAXE ... . How come?

In case of a true two-wire SerialPower interface, a Slave node may communicate during an assigned time slot (with only the pullup resistor at the Master node defining a High logical level on the network) and may enforce a Low logical level (Interrupt or zero-bit) by shortening the wire connection through its slave-node MOSFet. The picture shows a scope impression of a Master message and subsequent Slave response message, as well as a drawing of the circuit through with the two wires are connected through the slave side at low logical level imposed by the Slave:


It appears that in this situation the actual voltage difference between the network wires is not (even close) to 0V because there is a current that flows through the master pullup resistor and - at the slave part - through two rectifier diodes and the MOSFet. The voltage drop due to this current depends on R_pullup, the diodes' forward voltage and the MOSFet's conduction resistance R_DSon. Consequently, it appears that the voltage difference between the wires as seen by the Master input is approximately 1.25V, as I came to know through the scope analysis.

Interestingly, this voltage level is above the maximum level of a Low-logical level (see the Inputtype command for these levels depending on TTL- or Schmitt-Trigger input types), so the PICAXE would not have to accept the signal as such. Luckily, it appeared that I had coincidentally selected the only Schmitt-Trigger input that the 08M(2) has, namely C.2 (I discovered the issue since a change of input pin at the master 08M2 did not work out well, and C.2 is the only Schmitt-Trigger input ...), and this input still recognized the level correctly as a Low level, likely since this input type has a higher voltage limit on Low than a TTL-type port. Still, this is out-of-spec behavior that does need a trustworthy correction.

Luckily, the issue can be resolved through the comparator module that is also present on the 08M2 (although not supported directly on the M2-types by PICAXE-Basic, but still accessible/configurable through POKESFR). I will use it in combination with the internal Voltage Reference (FVR) at 2.048V such that the input signal is routed through the comparator first (giving a nice 0.0V logical Low, thus the comparator acts as a signal conditioner) and then fed back into the PICAXE.

My take on this learning experience: Heavy testing and a good scope (and DPScope is!) are indispensable for a stable solution ...

More to follow soon (hopefully the full implementation and documentation as well)

PS: May have to think what this means for the voltage level at other slave nodes as well ...

Last edited:


Well-known member
Seems like a hardware solution could also be applied at the Master serial input with an FET at R6 and the PICAXE to square-up the received input.
Tex: Indeed your external solution could be applied. Since the solution using the 08M2 internal comparator in combination with the FVR set at 2.048V appears to work very well too it will be the chosen solution here, only one simple resistor is needed (connecting the comparator output to the SERIN input). The comparator + FVR together work as a signal conditioner that gives a rail-to-rail signal to the serial input. The picture here below shows the red signal on the network before entering the comparator, and the blue signal after being processed by the comparator. :


The result is a clean signal (the PICAXE-08M2 is running here at maximum speed of 32MHz, the signal is still very square, so in the future I may investigate higher SERIN/SEROUT baudrates). The code part below shows how the comparator is configured (based on information from the PIC12F1840 datasheet on which the 08M2 is based):

REM Comparator needs 2.048V as a reference:  network input signal below this value is cut off to 0.0V bij comparator

REM Comparator has an output at C.2, according to datasheet it is required to set this pin as output explicitly then.

REM Define comparator settings:
SYMBOL CM1CON0_address = %1010001 'Address of control register 0
SYMBOL CM1CON1_address = %1010010 'Address of control register 1
SYMBOL valCM1CON0 = %10110100  'Comparator Control register 0 values: input (-) at C.1, inverted output at C.2
SYMBOL valCM1CON1 = %00100000  'Comparator Control register 1 values: use FVR output (2.048V) as (+)input of comparator
POKESFR CM1CON0_address, valCM1CON0
POKESFR CM1CON1_address, valCM1CON1

As a result of these findings the Master node diagram is altered slightly as shown below:


Additionally, R6 has been lowered from 10K to 1K as it appears that the microcontroller input pins have an estimated input capacitance of 50pF (which is larger than I initially expected).

My takeaway here:
  1. Even the small 08M2 has a comparator that shows to be extremely useful for signal processing.
  2. The comparator can be fully configured using POKESFR commands even though it is not supported with specific BASIC-commands for M2-processor types (the COMPSETUP command is valid for X2 types only).
  3. Due to this - and other earlier - improvements (as well as Womai's DPScope) the electrical design of the SerialPower network has become much more robust, giving hope that SerialPower II may soon function very well too.

PS: included below is a picture of the master node part of my prototyping hardware built using the famous Philips EE system from my youth. On the left is a modern PICAXE-08M2, on the right is a 50-year old 10nF ceramic tube capacitor, and the resitors look like 1/2 Watt types but actually are old-fashioned 1/4 Watts from the Philips kit ... :O)


SerialPower I v4.0 is getting close to completion now.
Last edited:
Loving the prototype board!
OT: It is extremely satisfying to still use the prototype system that I grew up with as a teenager thirty-forty years ago (its production ceased after 1985). This system allows clean layouts closely resembling the circuit diagram without a lot of wire spaghetti and therefore provides for visually attractive layouts even for complex designs (and also makes it easy to spot wiring errors etc.). The links here show a rather extreme example of what is possible: a re-designed FM-radio I published a year ago: link1, link2 . I recall that in the seventies the Philips EE system was rather popular in the UK as well.

Last edited:


Senior Member
... prototype system that I grew up with as a teenager ... Philips EE system ...
Same for me at 12, a long time ago. Although I was not able to get some of the more complex circuits working ; perhaps some poor connections. Later, I used solderless breadboard (good quality model) but I encountered some poor connections problems after time, may be due to some glue remaining on wire leads (tape).

Because in case of a prototype you are not certain that your design will work, adding some uncertain connections could be hell. Now, I only trust soldered connections (original breadboard, prototype pcb) ou wire wrapping


Well-known member
Jurjen, I didn't go back and try to find this in your previous posts, but have you done any testing with long network lines? Something like 300 or 400 feet?

I have tested with a 10m (11 yards) wire length (no twisted pair) at maximum frequency (32MHz) in an in-house environment and no issues showed up. I can touch the network lines without leading to disruptions and a scope view only shows a minuscule noise increase. This likely is because of the network impedance being quite low and close to the value of the pullup-resistor combination (R5 + R8 = 470 + 470 = approx. 1Kohm) at the Master node, assuming a negligible power source impedance.

The area with a higher risk is located at the Slave node, at the signal line between the diode rectifiers and the Picaxe input. There the effective impedance is determined by R2 = 68K. Touching this line can disturb the transfer of messages (and once completely locked up the system) so EM-shielding of the slave node encasement is likely the best approach.

The next logical step then is to make the network more resilient against disturbances that in the current version could lock up the system, i.e. take measures to allow an automatic recovery to full functionality. I have some ideas for that, using 1) a smarter version of the master node program that once in a while registers processes anew and 2) the time-out possibility of the SERIN command allowing the slave node to reset itself (while remembering its state/processor speed!) and then resynch with the network. Stuff for V4.1 also (and proper documentation in the architecture doc), but first priority has the release of SerialPower II !

Last edited: