Announcement

Collapse
No announcement yet.

Default setting for Switchboard connections?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Default setting for Switchboard connections?

    As I am trying to understand how to set the parameters of the crossConnect() method, I noticed that included scripts like McastCounter do not call the function and work with Connect applications as well as Snappy scripts only.

    If I upload the script McastCounter to the Snapstick and then run the sample application provided in the Connect Python Package Manual I can establish communication and everything works as expected. I though that in in order to do that, the call to
    crossConnect(DS_UART1, DS_PACKET_SERIAL) needed to be present in the code uploaded to the Snapstick so it can comunicate and call RPCs in the Connect app.

    Does this mean crossConnect(DS_UART1, DS_PACKET_SERIAL) is the default state? Is it possible to upload the McastCounter code to a remote node and have a "blank" Snapstick acting only as a bridge or relay, passing messages received over the air to the UART to be read by the Connect app?
    What would be the default arguments if I were to invoke the crossConnect() method in this case in the stick?

  • #2
    Yes, crossConnect(DS_UART1, DS_PACKET_SERIAL) is the default (or DS_UART0 on radios with only one UART). It has to be the default, since it would otherwise be impossible to connect a new module to a PC and actually do anything with it.

    Comment


    • #3
      Originally posted by jasonharper View Post
      Yes, crossConnect(DS_UART1, DS_PACKET_SERIAL) is the default (or DS_UART0 on radios with only one UART). It has to be the default, since it would otherwise be impossible to connect a new module to a PC and actually do anything with it.
      Thanks for your response. I'm having trouble understanding how some of the scripts behave. For example, in the protoSleepCaster code this appears:

      # Don't try to mcast rpc's over PacketSerial link
      crossConnect(DS_PACKET_SERIAL, DS_NULL)

      and then later a method calls this line

      mcastRpc(1,2,'setButtonCount',buttonCount)

      How can this be possible if the first statement disables communication. Is the scope of crossConnect() limited to the method in which is called and then switchboard returns to the default?

      Comment


      • #4
        Packet serial is used only when talking to another SNAP implementation (usually a PC running Portal or SNAPconnect, but could be another radio) over a UART connection. It has nothing to do with the exchange of RPCs or transparent serial data over the air.

        If a radio is known not to have any other SNAP device to talk to via its UART, then there's no downside to disabling packet serial, and there's the advantage that it doesn't ever have to send a packet over both the packet serial and RF interfaces. This is useful on a radio that spends most of its life asleep, since the RF packet is likely to complete much faster than the serial packet (because of the higher baud rate), so the radio can go back to sleep that much faster.

        Comment


        • #5
          Originally posted by jasonharper View Post
          This is useful on a radio that spends most of its life asleep, since the RF packet is likely to complete much faster than the serial packet (because of the higher baud rate), so the radio can go back to sleep that much faster.
          This is especially the case for nodes that receive mcast packets with TTL greater than 1. The serial port (when PacketSerial is enabled) is a valid interface for routing packets. So, the radio forwards the message out over the air and serial port. However, it must wait much longer for the serial port to finish up before it is cleared to perform other tasks such as sleeping.

          Disabling Packet Serial (i.e.X-Connecting to NULL) is not necessary in all cases, but can help if you see a long delay in your application or require really low-power operations.

          The only drawback is that you will have to reestablish the packet serial connection (erase script and reboot will work) before it will talk to Portal over the serial port again.
          sigpic
          Proven Solutions for the Internet of Things
          www.synapse-wireless.com

          Comment


          • #6
            Originally posted by Jheath View Post
            Disabling Packet Serial (i.e.X-Connecting to NULL) is not necessary in all cases, but can help if you see a long delay in your application or require really low-power operations.

            The only drawback is that you will have to reestablish the packet serial connection (erase script and reboot will work) before it will talk to Portal over the serial port again.
            I am glad I asked this since low-power is one of the requirements of my product. I plan to have nodes connected to a Connect app running on Windows, using the Snapstick as gateway. So as long as I keep the default settings on the stick it should work. I got a serial cable and a protoboard to reprogram the other nodes if necessary.

            Thank you both for the great advice. Back to work now...

            Comment

            Working...
            X