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

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

  1. #11
    Member
    Join Date
    Jan 1970
    Location
    Washington (state), USA
    Posts
    79

    Default Flipping a switch

    I've been spending way too much time thinking about this stuff over the last day. Here's where my thoughts are now:

    First, I needed to stop thinking about "sending processes" and "receiving processes." Those are good descriptions of the implementation model (how the network stack actually works) but they weren't working for me as mental models. Unfortunately for me, the variable and constant names reinforced the implementation model as my mental model and I had some trouble getting past that.

    What shifted my mental gears was re-reading the programming guide. In that section you refer to the packets on the network as "messages" and to a generic "Display" process. That's what it took for me to get the right mental model in my head, what's being sent on the network are messages, not simply process IDs.

    Once I made that leap, I could start thinking about the messages on the network in new ways. I've come up with two different classes of messages that you can send: command messages and notification messages.

    A command message is one that tells a listening process to do something. The sending process decides that something needs to be done ("I need to flash the LED on the master node.") and then sends a command that the master node executes.

    The examples that I've mentiond from the docs are both of this type: IDflashLEDmasterNode is a command message -- it tells the master node to flash it's indicator LED. The generic "Display" process that you refer to is also a command message, one node is telling another node "display this data."

    A way of reinforcing this type of command is by using a naming convention that indicates that the sending process is telling the receiving process what to do: when the master node receives a message with the destination IDflashLEDmasterNode it calls the process doFlashLEDmasterNode.

    A notification message is one that puts information out on the network but is not asking for an action to be performed. For example, take a node with a temperature sensor. It runs a loop checking the current temperature and checking it against the previous temperature. If the two differ, the node creates a message that looks like this:

    IDtemperatureChanged, IDnodeIdentifier, oldTemp, newTemp

    Other nodes on the network can listen for IDtemperatureChanged messages and then act on them as necessary, using the additional information in the data packet to make decisions about what to do: one node could display the temperature on an LCD or LED, another might use the information to turn a fan on or off, another might check that the temperature falls between two extremes and sound an alarm if the temperature goes outside of those extremes. The point is that unlike a command message, an notification message is not calling for a specific action. The sensor node does not send out a "Display the temp" message, nor does it send out a "turn on the fan" message, it simply says "here where I am the temperature changed from this to this" and other nodes decide what to do with that information.

    A naming convention for notification messages is to name the process for what notification message causes it to run. For example, a process that handles a IDtemperatureChanged message might be named onTemperatureChanged.

    Command messages are inherently tightly coupled. They require that the sender know what message to send to get another node to take an action. In the example code, the readKeyPressed process has to know that the master node implements the flashLEDmasterNode process, resulting in tight coupling between the two processes.

    Notification messages offer loose coupling, the sender does not know which other node on the network will use the information, or even if any node on the network will use the information. The receiving node will use the messages that come across the network, or take appropriate action if no messages are being received.

    Command messages have their place, because the master node is primarily in the business of sending command messages: "If you have any messages to send, do it now" repeated over and over for each message sender on the network.

    I'd probably better leave this for now. Too many things jumping around in my head. For example:
    IDavailableTimeSlot should probably be 254 instead of 1. Why? Every other packet sent on the network is availableTimeSlot, and if you use 254 (%111111110) instead of 1 (%00000001) the network doesn't get pulled down as often -- same reason that unused bytes in a network frame should be set to $FF.

    Hmm... that means the first user process ID I use should be 253 (%11111101)...

    Really, I'll stop...

    Chuck
    Last edited by puddlehaven; 16-10-2007 at 19:17. Reason: Those darn typos that only show once you've posted the message.

  2. #12

    Default

    I'm having some trouble implementing my applications in this framework, and I'd like to see some more examples or demo code, possibly from other members, such as puddlehaven, if he's willing to share. I will of course give credit and post here once i have something to show but so far ive been stuck on the simplest tasks and thus dont have much to show besides my project concept and failing code..

    My application is a tracked robot with two decks, one for the primary applications, and the other for secondary, and less important things such as temperature sensors, camera etc.
    In the long run I'm planning on using it for a combination of GPS coordinated missions, avoiding obstacles, and been able to either observe or override it on any level

    So far my list of nodes/processes looks roughly like this:

    Master \ ___ Engine module - listens for simple forward/backward commands
    |___ Comm Module TX - takes packets to put on RF network
    |___ Comm Module RX - listens for packets from RF network
    |___ "Power supply" - listens for cmds regarding light control and
    | manual power override or reroute for heavy
    | applications such as engines)
    --|-- second story
    |
    |___ Sensor Engine module - listens for position data or preset areas, e.g. left
    | (this is for controlling a pan/tilt turret)
    |___ Sensor Module - reads sensor data from the ultrasonic sensor, temp sensor etc
    |___ Interface module - this would consist of either a serial interface or
    | LCD+keypad to debug and override things directly
    in case RF fails

    Now one of the things I'm having the most trouble understanding how to do is to properly catch both RF (RX) data while properly supporting the network protocol. I see that puddlehaven is planning on using some of the same applications as I am, and has spent some time on this already, so please, could you share more of your problems and/or successes, and possibly some application code, then that would be greatly appreciated.

    I'm also eagerly waiting for the sensor example code that is to follow in the 2.1 version of the documentation/paper, which reminds me; great work on the protocol Jurjen, it saved me trying to do something much similar, but on a much less successful level

  3. #13
    Member
    Join Date
    Jan 1970
    Location
    Washington (state), USA
    Posts
    79

    Default

    I'm still working on my mental model for how to make a network like this work, but here's how I'm thinking right now:

    I split the nodes on my network into two types, sensors and actors. This is a conceptual distinction, for example my display nodes acts as both as sensor (it announces the time to the network) and as an actor (pulling data off the network and displaying it).

    Each sensor node implements a single message handler that will respond to available time slot requests. The node registers the handler during network initialization and then settles into its main processing loop.

    Once every pass through the process table the master nodes asks each sensor node to put data on the network. Sensor nodes only respond when the readings that they are responsible for change. This means that in many cases the sensor nodes can desync from the network, only re-syncing when there is data to send. That way the node can run it's main processing loop without interruption, unless there is new data to send.

    When sending data on the network, the sensor node is responding to the message ID that it registered during network initialiaztion, but it is sending a message that indicates the sensor that has changed.

    So in your case, I would probably do something like this. First, I'd define two message IDs:

    • IDrxNode -- Node ID for the RX node.
    • IDrfDataReceived -- Message ID for new data from the RF receiver.

    The RX node would register its node process during initialization and then, after it has registered its node ID in the master process table, desync from the network and enter its main processing loop waiting for information to be transmitted. When it receives a message, it stores the data in memory, resyncs to the network, and then on the next available time slot granted to the IDrxNode process ID it sends an IDrfDataRecieved message to the network. After the data is sent, it desyncs from the network to avoid interruption while waiting for the next message to come in.

    Here's some pseudo-code for the RX sensor node's program:

    Code:
    PowerOnReset:
    
       ; Boolean or byte variable. Set to true when the node responds
       ; to the roamForSendingProcess message.
       initialized = false
    
    WaitForInitialization:
    
       IF initialized = false THEN WaitForInitialization
    
       Desync from the network
    Main:
    
       Read receiver.
       
       IF the readings has new data THEN
          store the data so it can be sent on the network
    
             Message frame: IDsensorReadingMessage, IDnodeID, DataByteH DataByteL
    
          Synchronize to the network so the send routine can hear it's available time slot
    
          WaitForSend:
             If data not sent yet, GOTO WaitForSend
    
          Desync from the network
       ENDIF
    
       GOTO Main to repeat loop.
    Does that make sense? Or did I leave you more confused than when I started?

    Chuck

  4. #14

    Default

    Ahh, yeah that cleared things up, thanks

  5. #15
    Member
    Join Date
    Nov 2007
    Location
    East coast, USA
    Posts
    39

    Default

    Very interesting protocol. It seems similar in some ways to the 1-wire interface from Dallas Semiconductor, which pulses current instead of reversing it.

    http://en.wikipedia.org/wiki/1-Wire
    http://www.maxim-ic.com/products/1-wire/

    That system uses a wickedly clever device detection and enumeration scheme that might help development of your protocols:

    http://www.maxim-ic.com/appnotes.cfm/appnote_number/187
    Last edited by tikeda; 09-11-2007 at 20:17.

  6. #16
    Senior Member
    Join Date
    Jan 1970
    Location
    Groningen, The Netherlands
    Posts
    469

    Default

    A reply to some of puddlehaven's (Chuck) remarks:

    • Slave node timing disruption due to network interrupts (See first page of this thread): This is a correct observation which I had not thought of, but can be remedied by using the following "interruptible pause" code (using pause entities approximately equal to the duration of one message frame, 50ms):
      Code:
      REM 1-second "Interruptible Pause" code
         FOR i = 1 to 20
         PAUSE 50
      NEXT
      Thus a candidate for the updated programming guide ...
      .
    • (Same posting on first page) Chuck correctly indicates that one should take care that all slaves need to be ready before the master node starts operating the network (i,e, the master node start-up time should be long enough. Easily done and understood, but easily forgotten also ...
    • Using a thinking model like Chuck proposed (two types of messages: Command messages and Notification messages) may indeed greatly help in building applications, and I gladly include this suggestion in the Programming Guide
    • The network protocol completely abstracts from physical nodes as the communication is principally defined between processes, not nodes (which I think is a very important strength of the network concept). I would thus advise to always think in terms of processes instead of nodes (which of course in practice often are coupled using a node-specifc process): Thus I would propose in Chucks message format

      IDtemperatureChanged, IDnodeIdentifier, oldTemp, newTemp

      to replace IDnodeIdentfier with IDTempSensorProcessIdentifier, as the temperature sensor process may be on any node. This is just naming convention, but it is tied to the earlier thinking model discussion as well.


    Regards,
    Jurjen
    Last edited by kranenborg; 09-11-2007 at 21:28.

  7. #17
    Member
    Join Date
    Jan 1970
    Location
    Washington (state), USA
    Posts
    79

    Default

    Quote Originally Posted by kranenborg View Post
    The network protocol completely abstracts from physical nodes as the communication is principally defined between processes, not nodes (which I think is a very important strength of the network concept). I would thus advise to always think in terms of processes instead of nodes (which of course in practice often are coupled using a node-specifc process): Thus I would propose in Chuck's message format

    IDtemperatureChanged, IDnodeIdentifier, oldTemp, newTemp

    to replace IDnodeIdentfier with IDTempSensorProcessIdentifier, as the temperature sensor process may be on any node. This is just naming convention, but it is tied to the earlier thinking model discussion as well.
    From a theoretical standpoint I agree with you. From an implementation standpoint it can make sense to use a single sending process per node no matter how many messages are sent by the node. This is especially true when you're using multiple identical nodes in a larger network.

    If I were going to write it up as advice I'd say: Use a process ID for each message sender on your network until you are in danger of filling up the process table on your master, and then start looking for ways to consolidate message senders.

  8. #18
    Senior Member
    Join Date
    Jan 1970
    Location
    Groningen, The Netherlands
    Posts
    469

    Default

    In order to allow the SerialPower concept to be easily used in practice for application building I have decided to apply a Creative Commons license for clarity. I have updated my website and codes accordingly, and the following code snippet may be used in any application code explaining the particular license used:

    Code:
    REM STATEMENT OF COPYRIGHT
    REM Copyright (C) 20XX, FIRSTNAME LASTNAME
    REM (xxx(at)yyy(dot)zzz)
    
    REM This work is licensed under the Creative Commons 
    REM Attribution-Noncommercial-Share Alike 2.5 (Swedish port). 
    REM To view a copy of this license, visit 
    REM http://creativecommons.org/licenses/by-nc-sa/2.5/se
    REM To view a translation of this license in English, visit:
    REM http://creativecommons.org/licenses/by-nc-sa/2.5
    REM or send a letter to 
    REM    Creative Commons, 
    REM    171 Second Street, Suite 300, 
    REM    San Francisco, California, 94105, USA.
       
    REM In short form (me, my = holder of copyright):
    REM   * You may use, adapt, and distribute this work. 
    REM   * You must give credit to me when using this code in your application.
    REM   * If you use my code commercially, I want my share.
    REM   * You may share your adapted code (now with you as holder of copyright) 
    REM	  on the condition that the same license conditions are applied.
    
    REM NOTE: The network architecture of this work was originally developed by Jurjen Kranenborg.
    Note that the last sentence highlights that I wish to be credited for the network concept fundamentals in any applications (code an docs made by other authors and thus with other copyright holders)

    Regards,
    Jurjen

  9. #19
    Member
    Join Date
    Jan 1970
    Location
    Washington (state), USA
    Posts
    79

    Default Network example

    I've posted a description of the SerialPower network that I've been building from Jurjen's ideas. I've put together a master node, a sensor node, and a display node. You can see a description of each node, pictures of the nodes on their breadboards, and take a look at the code on my new Web site.

    http://www.bramblyhill.com/Picaxe/serialPower.aspx

    Chuck

  10. #20
    Senior Member
    Join Date
    Jan 1970
    Location
    Groningen, The Netherlands
    Posts
    469

    Default

    Hi Chuck

    Great website (just scanned quickly, but looks very impressive with lots of useful practical information)!

    One small remark: the "read more" link in the box "Chuck's own research network" doesn't work: netintro.aspx -> netinfo.aspx (as is in the equivalent link left at the top that does work)

    /Jurjen

Bookmarks

Posting Permissions

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