Shop OBEX P1 Docs P2 Docs Learn Events
In need of RTC for distributed BS2-XBee modules. — Parallax Forums

In need of RTC for distributed BS2-XBee modules.

trookstrooks Posts: 228
edited 2014-03-06 11:32 in BASIC Stamp
?

I am working out how to make certain that communications goes smoothly and timely commands are delivered via RF connected modules.

I had the whole thing worked out using discrete components connected via hardware. Once I started working on the RF connectivity I realized I may have overestimated my capabilities a bit.<sad grin>

Now I am writing software to do what all those component modules built over all those months were doing. This system will only work with unified clocking in a time slice multiplexing scheme. It needs an external reset so that multiple units can be synched together. What I would really like is a 'clock in a can' that I could breadboard onto each BS2 module.

Advise from anyone with experience or ideas will be most appreciated.

Tim

Comments

  • stamptrolstamptrol Posts: 1,731
    edited 2014-03-05 07:05
    Other than telling you about numerous clock modules available, we can't give you much help without a bit of information about your system.

    How about a block diagram of the network? Or even how many nodes on the system. Or, how much data is being transferred between nodes? Can it be implemented in a master-slave configuration?

    Cheers,
  • trookstrooks Posts: 228
    edited 2014-03-05 08:33
    stamptrol wrote: »
    Other than telling you about numerous clock modules available, we can't give you much help without a bit of information about your system.

    How about a block diagram of the network? Or even how many nodes on the system. Or, how much data is being transferred between nodes? Can it be implemented in a master-slave configuration?

    Cheers,


    All modules including the control are BS2-XBee.

    Circular topology with control in the middle polling each of 2-n remotes in turn and storing the response. A single byte is all that is needed but I have to calculate/experiment with various communication modes of the XBees to find the optimum(least time overhead) method.

    At the end of each poll cycle the control does and/or/nand/nor calculations and broadcast a short command string to all modules. Each remote module looks at specific bits and takes action/actions and sets bits for next poll response.

    The process repeats.

    Initially there will be a maximum of 4 remotes. To go beyond that many and still maintain functionality will require faster processors and faster communications.



    Thank You for your consideration,

    Tim
  • FranklinFranklin Posts: 4,747
    edited 2014-03-05 12:01
    Since the center node is polling for the data what is the timing restraints? Why do they need to be synced? What resolution do you need between nodes?
  • stamptrolstamptrol Posts: 1,731
    edited 2014-03-05 12:20
    Very good. The master in the center can be responsible for time keeping and sending the time to each node as required.

    In a very similar system I've built, the master broadcasts to all nodes, in a message string of 3 or 4 bytes. (at 19.2 K). Within the bytes is the address of the node which is supposed to respond.

    You don't talk about the cycle time, but as an example, my link was transferring rotary encoder pulses over the XBEE link and doing real-time measurement and all the control logic for the rest of the machine.

    Cheers,
  • trookstrooks Posts: 228
    edited 2014-03-05 16:17
    Franklin wrote: »
    Since the center node is polling for the data what is the timing restraints? Why do they need to be synced? What resolution do you need between nodes?

    I need to get precise control over mechanical functions. Without precise timing things will not mesh as they should. My best estimate of how much wiggle room I have is +/- 5ms but the only function that is that tight is the very last one to be sent.

    The end signals go to an assortment of solenoids for either pulling or pushing pawls and stop levers.

    After further thought I probably should just use the broadcast signal as the start of the timing and adjust the software of each module to gain more accurate synchronization.


    Thanks for the input,

    Tim
  • trookstrooks Posts: 228
    edited 2014-03-05 16:45
    stamptrol wrote: »
    Very good. The master in the center can be responsible for time keeping and sending the time to each node as required.

    In a very similar system I've built, the master broadcasts to all nodes, in a message string of 3 or 4 bytes. (at 19.2 K). Within the bytes is the address of the node which is supposed to respond.

    You don't talk about the cycle time, but as an example, my link was transferring rotary encoder pulses over the XBEE link and doing real-time measurement and all the control logic for the rest of the machine.

    Cheers,



    I feel as though I could not see the forest for the trees. (DUUH - head slap)

    I should have been using the broadcast as timing start and adjust the software of each module so that they all arrive at the final command in the same number of instruction cycles.

    Also you mentioned 19.2K as your communication speed. I am not yet very far into "Getting Started with XBee Modules" since I ran out of batteries and am waiting for at least one more reason to go to town before I can get more. So far everything was done using 9.6K and I did not realize that faster speed was available. How fast can XBees communicate?


    Much thanks for your help,

    Tim
  • Mike GreenMike Green Posts: 23,101
    edited 2014-03-05 19:42
    The communications between the xBee and the Stamp can be as fast as the Stamp can handle (9600 Baud for the BS2, 19.2KBaud for the BS2px). They can communicate with a Propeller at 115.2KBaud for example. The communications speed among the xBees is variable and probably not fast enough for what you want. Remember that the xBees communicate in terms of packets. They buffer data and wait until the buffer is full or a time-out occurs before transmitting the packet on hand. If it's an electrically noisy environment or there's a lot of other xBee or other traffic going on using the busy 2.4GHz band, the xBees may have to retransmit the data and that takes a variable amount of time. You can override the packet size and some of the retry timing with commands
  • trookstrooks Posts: 228
    edited 2014-03-06 07:09
    Mike Green wrote: »
    The communications between the xBee and the Stamp can be as fast as the Stamp can handle (9600 Baud for the BS2, 19.2KBaud for the BS2px). They can communicate with a Propeller at 115.2KBaud for example. The communications speed among the xBees is variable and probably not fast enough for what you want. Remember that the xBees communicate in terms of packets. They buffer data and wait until the buffer is full or a time-out occurs before transmitting the packet on hand. If it's an electrically noisy environment or there's a lot of other xBee or other traffic going on using the busy 2.4GHz band, the xBees may have to retransmit the data and that takes a variable amount of time. You can override the packet size and some of the retry timing with commands

    Mike,

    Thanks for the additional info.

    Does the tutorial "Getting Started with XBee RF Modules" cover those commands that you mentioned?

    Also will a BS2px plug in to a BOE in place of the BS2 and work the same only faster?

    By the time I finished testing all the XBee modules on each of the adaptor boards I had run out of batteries. I did discover that after 12 hours a .001% fail rate using 5 AA batteries on the loop back test began to climb appreciably. Is it a fair assumption on my part that a faster speed will also mean a shorter battery life?

    Since my budget for this phase of the project is way into the red I am having to curb my trips to town to pick up stuff since my F-350 crew cab long bed 4WD gets abysmal gas mileage. But it does get me to all the best fishing holes and carries my whole camp setup.


    Thanks again,

    Tim
  • Mike GreenMike Green Posts: 23,101
    edited 2014-03-06 07:26
    The BS2px will indeed plug into the BOE in place of the BS2 and will work faster and with more features. Be aware that timing values for pretty much everything but PAUSE will be different. This includes SERIN and SEROUT Baud parameters. The faster Stamps also draw more power. The comparison chart on Parallax's website gives the details. The xBee will draw more current though with peaks during transmission. If you decrease the time-out, you'll increase the average power demand.

    The "Getting Started" tutorial (as I remember) doesn't go into these commands. You have to read the reference manual from Digi.
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2014-03-06 11:32
    stamptrol wrote: »
    Very good. The master in the center can be responsible for time keeping and sending the time to each node as required.

    In a very similar system I've built, the master broadcasts to all nodes, in a message string of 3 or 4 bytes. (at 19.2 K). Within the bytes is the address of the node which is supposed to respond.

    You don't talk about the cycle time, but as an example, my link was transferring rotary encoder pulses over the XBEE link and doing real-time measurement and all the control logic for the rest of the machine.

    Cheers,

    That's exactly what this video is demonstrating. I am building a weather station and the time is gotten from a GPS module outside with the external sensors. All the telemetry is sent in via XBee modules and the time is broadcast to everything at once. Some modules receive a command to respond with data as well. Fun stuff! The outside sensors are solar powered and run off an SLA battery at night.

    http://www.savagecircuits.com/showthread.php?211-XBee-Projects&p=1008&viewfull=1#post1008
Sign In or Register to comment.