​ ​ ​ ​ "SerialPower" true two-wire data+power network - Page 3
Page 3 of 8 FirstFirst 1 2 3 4 5 ... LastLast
Results 21 to 30 of 71

Thread: "SerialPower" true two-wire data+power network

  1. #21
    Senior Member
    Join Date
    Jan 1970
    Groningen, The Netherlands



    One small remark about the size of the back-up capacitor on the slave nodes: A very large value will cause a large inrush current on the network when it is started up, and maybe a power source with relatively large internal resistance (i.e. battery) may not be able to deal with that. For a slave node that I use with one LED a 100uF capacitor is excellent (without the LED a much smaller value probably can be used). Of course you can also test by decreasing the capacitor size and see at which value the node stops to respond.


  2. #22
    Senior Member
    Join Date
    Jan 1970
    Groningen, The Netherlands



    A question to wilf_nv: About a year ago you mentioned plans to apply the SerialPower network to a high voltage control PLC application (see the end of the following thread: http://www.picaxeforum.co.uk/showthread.php?t=5399). As I am interested in applications as well (for example those as documented by puddlehaven: http://www.bramblyhill.com/Picaxe/serialPower.aspx) I wonder how far you have come.

    Also to hwinter: did you manage to get your version of the network operational?

    PS: I just saw that puddlehaven now has reported on some real expansion plans for his SerialPower application, including direct coupling of a SerialPower network to the Internet: http://www.bramblyhill.com/Picaxe/plannedNodes.aspx

    Last edited by kranenborg; 02-02-2008 at 10:07.

  3. #23


    I'm a bit confused on how this network works...

    Wheres the Ground Cable?

  4. #24
    Senior Member
    Join Date
    Jan 1970
    Groningen, The Netherlands


    @ xnederlandx:

    In the documentation I have described three ways to implement the network practically:

    1) Power and data via two non-polarized (i.e. interchangeable) wires
    2) Power and data via two polarized wires (1 GND, 1 power & data)
    3) Power and data separated (simple diode-mixing network, 3 wires: GND, Vcc, data)

    In case 1 there is no GND wire because GND, Vcc and data levels are generated only locally in the slave nodes using the 4-diode DC rectifiers + fifth diode towards the uC's Vcc pin. A high level is created using a voltage difference between the wires (either for 1-bits during communication in a timeslot, or for power transfer outside the timeslots). A low level is generated by effectively short-circuiting the network, used for sending an interrupt or transmitting a 0-bit. Note that the master node defines the default high level, either actively via a high-side mosfet (for power transfer), or passively via a pullup resistor (for network communication). This is the most flexible option.

    In case 2 there is a predefined GND line, therefore only one diode is needed in the slave node network interface. This is the cheapest option of course.

    In case 3 everything is defined in the "regular" way. Still the primary benefit over standard RS-232 comms (via serin/serout) is that a complete message protocol for comms between high-level processes is defined, allowing messages to be sent between any pair of processes located on any combination of nodes. This also applies to cases 1 and 2.

    I hope this helps a bit, see also the introduction section in the architecture document on my website.

    Last edited by kranenborg; 25-02-2008 at 21:58.

  5. #25
    Senior Member
    Join Date
    Jan 1970
    Groningen, The Netherlands

    Default SerialPower V3.0: "the shape of things to come"

    Dear Forum members,

    I have been (slowly but steadily ;o) updating the SerialPower network stack and documentation since last year, and will be ready to publish a new version of the stack (V3.0), new examples as well as strongly upgraded documentation in about a month.
    Here is a view on the things to come (with a few sample cases for testing), and I am happy to take comments on suggestions, improvements and of course mistakes:

    Hardware-selectable network operation speed (4 - 8 MHz)
    An optional swith at the master node that is read at power-up allows the complete network to be operated at double speed (8 Mhz) without the need to reprogram or configure the individual slave nodes. Sometimes one would like to run at maximum speed, in particular in complex setups where lots of processes may use timeslots, but large networks pose some significant (capacitive) loading as well, in particular when they are based on the true two-wire approach. The switch allows rapid testing of the maximum throughput capability of the network. Without the switch the speed defaults to 4 MHz (a programmed internal pullup guarantees proper operation in V2.X based master node hardware that does not implement the switch). Of course a software switch can be programmed instead as well. The switch information is included in a network status message that is sent by the master node as the first message after power-up. The message is read, acted upon and saved in RAM for later use by all network slaves.

    Hardware update: Increased drive capability of the Master node, stability of Slave nodes
    The master node in its current configuration appeared not to be able to drive large capacitive loads at 8MHz. After changing some resistor values and a repositioning of the LED at the driver stage, the master node now can drive a capacitive load at 8Mhz of at least ... 0.22uF ! (tested by putting a 0.22uF capacitor across the network connectors). This should enable to build large applications based whilst still using a true two-wire network comfiguration (another option is of course the simple diode-mixing setup which does not have this issue).
    At the slave node one resistor was lowered in value so as to increase the stability of the network (defining local slave node ground level more firmly at the input stage of the slave node).

    I am currently developing a set of examples that may be useful for understanding the operation of the SerialPower concept and for rapidly developing applications (and last but not least: helping me to understand SerialPower and to indentify unsolved issues!). The example code is extensively documented. Below, three simple examples are included dealing with switch reading (tested) and temperature sensing/reporting at a given threshold temperature (not yet tested, but I am quite sure it will work). All examples can be tested in a simple test set-up using one master node and one or two slave nodes (all 08M based).
    More examples (extensions of the temperature application) are on the way, dealing with multiple sending processes per node, on-the-fly timeslot generation for bandwidth management in large systems etc.
    The master node software now also includes a software switch specifically for the temperature test versions, allowing the messages with temperature information to be displayed on the terminal using SERTXD. The switch was necessary in order to make sufficient temporary room on an 08M-based master node (which becomes a "tight jacket" for the master node network software; still I want the standard master node stack to fit in the 08M); for the temperature test cases the flasLEDmasterNode process that is not used is not compiled in order to save the bytes for the extra temporary SERTXD command. After testing the switch can be disabled, restoring normal functionality.

    The simplest network hardware for testing is of course the simple diode-mixing hardware (see picture below). Do not forget to enable the proper option in the slave node software in that case.

    I can strongly recommend to do a file comparison between the switch example and temperature example T2 (WinMerge is a very useful open source program for doing such!). This comparison clearly shows which parts of the slave code are application-dependent, and which parts can be left untouched (most of it, actually).

    Note that the standard master node configuration is completely application independent. Furhthermore, the master node software is independent of the network hardware type. The really curious may actually compare the old and new versions of the master node software to see what has changed.

    Software maintenance:
    There is no need anymore to maintain separate versions of the slave node software for different network hardware (true two wire or simple diode-mixing (three wire)). A software switch setting generates the proper code. Care is neede though for the proper setting, otherwise the FET at the slave node will be destroyed, as may the rectifier diodes).

    Software changes: Network stack
    Two items have been added to the network stack:
    - a networkConfigProcess (all slave nodes) that reads/stores the network status information from the master node, and sets the proper node CPU speed accordingly.
    - a helper routine called "checkReadyToPrepareNewMessage" (only useful for nodes with sending processes) that postpones putting new message information in the assigned RAM locations until the previous message information has been assembled into a network message and sent by the network stack. While waiting the node listens/responds to other network messages, as the waiting loop is interruptable. This is an operation that will very often be required, and therefore it has been included as a standard routine in the network stack.
    - IMPORTANT: the ID numbers of IDnoProcess and IDallProcesses have been reversed. IDnoProcess = 0 is the new definition, as this ID is often used and less initialization code is required (RAM memory is clear at power-up of the picaxes; a full network stack becomes quite "heavy" on a 08M, so every byte of user program memory gained counts).
    - IMPORTANT: the number of free, user-available registers has decreased with one due to the introduction of the new "checkReadyToPrepareNewMessage" routine, which consumes B8. This should be kept in mind when porting V2.X apolications to V3.X. Registers B0-B7 (W0 - W3) are available for user applications. There is a lot of RAM space available for user storage /temporary register save locations.

    Process synchronization (advanced, large systems)
    Optionally (using a software switch) the slave nodes can save any latest received slave message in a special RAM location, allowing processes in the slave body to monitor them and use the information to synchronize with other processes elsewhere without the need to implement the latter processes themselves. This greatly simplifies the programming model for more complex applications.

    The SerialPower architecture document will be significantly updated, focussing on application building and including the items above. Comments from users (puddlehaven and others) will be incorporated. The website will be changed as well for better accessability.
    Code documentation on the network stack routines has been added significantly (see examples), the code should now be completely self-explanatory. Furthermore some small corrections were performed in the explanations in the code itself.

    Licensing upgrade (Creative Commons)
    The license version has been upgraded to V3.0 (2008).

    The following two pictures show the updated designs for respectively the Master Node and the Slave Node circuits. Changes are indicated in red:

    The simple diode-mixing netwrok hardware as shown below provides a quick and simple way for testing (as well as a very practical way of realizing a network without combined power/comms lines):

    The following links to the updated V3.0 software (Master Node and slave node example applications) are available (the code contains extensive documentation, including required hardware for the example applications):

    Best regards,
    Last edited by kranenborg; 29-03-2009 at 20:40.

  6. #26
    Senior Member
    Join Date
    Jan 1970
    Groningen, The Netherlands


    Somehow I could not get the "temperatureTestMode" switch in the master node software to do what it should do, and therefore removed it (and the associated code changes) from the master node code.

    This implies that:
    - The switch test example can be run on just two nodes (1 08M master, 1 08M slave)
    - The temperature exampes can be tested on three nodes (with two 08M slave nodes), one slave node implements the given "readTemperatures" code, furthermore one has to write a simple code on the second slave that implements the "displayTemperatures" process and sends the temepratures to the terminal via SERTXD

    Since nodes can be added to the network without any problems, one can start with the two-node switch test, and after succesful testing add a node.

    Last edited by kranenborg; 19-10-2008 at 01:03.

  7. #27
    Senior Member
    Join Date
    Jan 1970
    Groningen, The Netherlands


    Version 3.0 of "SerialPower" is now available, implementing all of the announced enhancements mentioned above.

    The "SerialPower" homepage ( http://www.kranenborg.org/ee/picaxe/twowirenetwork.htm ) has been completely redesigned in order to allow easy access as well as to provide an introduction to application development through a number of documented examples. An upgraded version of the architecture document can be found there as well (V3.0.1 uploaded some minutes ago, still some updates to be done but the hardware circuits are now correctly described).

    I am currently in contact with someone developing a complete public model railroad project. If you are planning to develop or actually developing "SerialPower"-based applications let me know so I can be of help.

    Best regards,
    Last edited by kranenborg; 10-04-2009 at 02:07.

  8. #28

    Default SerialPower inquiry re a possible peer-networking project



    kranenborg wrote 10-04-2009, 01:53 in:
    "Version 3.0 of "SerialPower" is now available,
    implementing all of the announced enhancements
    mentioned above."
    "I am currently in contact with someone developing a
    complete public model railroad project. If you are
    planning to develop or actually developing "SerialPower"
    -based applications let me know so I can be of help."

    kranenborg wrote 20-06-2009 22:01 in:
    "I appreciate this info because I am currently designing
    a fast and extended version of my SerialPower network
    architecture for X2 (and X1) picaxes which will allow
    much higher transmit rates as well as variable-sized
    messages (each message containing between 1 and 32
    databytes as described by the first "descriptor" byte
    of the message)."

    "That's all! Further detail and reference can be found
    in the architecture document. I am also willing to help,
    but please post your question/issue on the Picaxe Forum
    SerialPower thread so that others may help and get
    informed too."

    PicaxeSerialPowerNetwork_V3.0.pdf says:
    "The message format as depicted in Figure 2 may be altered
    at will (to be able to exchange more data at one instance),
    but it must have the same size for all messages. In this
    document I decided to stick to the 4-byte format, for only
    few PICAXE registers are then needed for handling the frame
    data elements."


    Dear Mr Kranenborg,

    I've studied all your cited SerialPower information.

    I'm wondering which "complete public model railroad project"
    it is, that you mention.

    I'm wondering how you are progressing on your 'fast+extended'
    (Version 4.0?) SerialPower architecture.

    The reason I'm wondering is because I have a germ of an idea
    that S.P. might provide a basis to port a inter-processor
    messaging scheme that colleagues in my model railway hobby
    group have developed - the whole thing is called: 'CBUS'.
    Port from:
    its current implementation:
    . high-speed network using CAN (Controller Area Network).
    . PIC nodes, Assembler code.
    an alternative implementation:
    . medium-speed serial network,
    . PICAXE nodes, Basic code.

    The messaging scheme used is a 'producer-consumer' model
    where all messages are delivered to all nodes, one or more
    of which may act upon receiving a message of interest.
    This mirrors your S.P. 'information messages'.

    Regarding scale, I quote from our documentation;
    A CBUS message consists of a ‘command’ byte and an ‘event number’.
    The command byte is used to set the number of bytes in the message
    and define the type of event.
    For layout control we only use at present an ‘ON’ event and an ‘OFF’
    event but for CAB bus implementation, a number of other ‘commands’
    are also used.
    As nodes need to know how to respond to an event, there needs to be
    a mechanism for teaching them.
    Each programmable node is given a node number (NN) of 16 bits or 2 bytes.
    If nodes are to be unique, the maximum number of nodes is 65536 or 64K.
    Each producer node is allowed a further 16 bit range for its events
    giving a possible 4.29 billion events!
    The actual event number in a message is comprised of the node number
    and the node event so the final event is a 32 bit number.
    This allows events to be traced to a particular node as well as
    preventing accidental duplication of events from different nodes.
    Ignoring the 11-bit CAN header, the CBUS message format is:
    <Opcode><Dat0> ..<DatN>
    <Opcode> the first data byte is the opcode which includes
    the length of the message in the upper 3 bits.
    i.e. data payloads of between 0 and 7 bytes are thereby accomodated.

    I can see that your S.P.4. proposal would do variable # of data bytes.

    Your current S.P. uses one byte for message id.
    What are your thoughts on the number of allowable msgids in a S.P.4.

    Your current S.P. uses one byte for node id.
    What are your thoughts on the number of allowable nodes in a S.P.4.

    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!

    Actually we carry node_number+node_event in data bytes, which
    covers multi-segment networks with repeater interconnections
    (CAN only allows 110 nodes per segment).
    That could also fit well with S.P.4., methinks.

    I assume you divide 'message ID' numbers into two groups/ranges ?:
    Those associated with 'command messages', second byte= dest node
    Those associated with 'information msgs', second byte= origin node

    Regarding S.P.3 you wrote:
    "At 8MHz a maximum throughput of over 20 messages per second
    (equals 40 bytes of information) can be reached."

    Have you any feel yet for the likely throughput of S.P.4.?

    Much info on the "CBUS" scheme on our Group website public pages:

    Any comments and/or guidance gratefully received.
    I'm happy to correspond off-list if you so wish.

    Rodney Hills
    Surrey, UK
    Last edited by rodnet; 10-06-2010 at 18:46. Reason: typo

  9. #29
    Senior Member
    Join Date
    Jan 1970
    Groningen, The Netherlands


    Hello Rodney,

    I am currently testing a beta version of SerialPower version 4 (i.e. the one with variable sized messages (1 to 32 data bytes) and much higher serial speeds than V3) on a PICAXE-28X1 configuration with one master and two slaves.

    This implementation includes now only 1-byte IDs like in V3, basically because 2-byte IDs require a more complex roaming procedure since it would take simply too long time to roam for all 65536 IDs after network power-up, although I have an idea how to handle that using a special protocol by regarding a 2-byte ID as an 1-byte group 1D plus an 1-byte localized sub-group ID. But ... first things first!


  10. #30


    Hello Jurjen,

    Thank you very much for the update on your progress.

    Please tell me, what serial baud rate(s) do you envisage
    V4 running at?

    I have acquired my first Picaxe processors:
    6 x 20M plus 4 x 20X2.
    Would both of these models be capable of running V4?

    Are the comm circuits and additional components the
    same for V4 as those that you already described for V3?

    If that's the case, I guess it may make sense for me to
    build and test a V3 network between my processors first.
    Then, later, to try V4 once you are in a position to ship
    the code.

    I hope that your V4 beta testing goes well.

    Regards, Rodney


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts