Announcement

Collapse
No announcement yet.

Sample Portal script disables SnapStick connectivity?

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

  • Sample Portal script disables SnapStick connectivity?

    I recently purchased a EK2100 kit. While playing with the scripts, I followed the recommendation at the end of the EK2100 User Guide and downloaded the protoSleepCaster.py to the rf engine in the sn171 board. I mistakenly also downloaded the one named protoFlasher.py to the rf engine connected to my SnapStick and, as you can guess, Portal does not recognize the stick anymore.

    All of the existing methods I have found in this forum seem to use a serial cable which is not included with the kit and I do not have available at home. I was surprised because the scripts as described do not seem to change the UART assigments so I suspect the issue is related to Portal not being able to talk to the devices while they are on sleep mode. Can anybody clarify this?

    Is there any method of forcing a sleeping device to accept commands from Portal? Keep in mind that the stick is not even being detected by Portal at the moment, giving the typical USB0:Read error. This are the only two engines I have available and they are both inaccessible so my options are limited. Any help would be highly appreciated.

    As a note, the Jheath sticky post does not mention what to do in my case. I believe it would be a good addition to the post to add instructions for this case. Even if it is only to say, as I seem to have found in other posts, that the only solution is buying a serial cable and using the sn171 board to reset the nodes.

  • #2
    Does "Erase SNAPpy Image" (from Portal's Options menu) allow you to select USB0 as the port? (I don't have a SnapStick on hand to check this.) If so, do that, and short pins 23 & 24 on the RFEngine when prompted to reset the device.

    Comment


    • #3
      Originally posted by jasonharper View Post
      Does "Erase SNAPpy Image" (from Portal's Options menu) allow you to select USB0 as the port? (I don't have a SnapStick on hand to check this.) If so, do that, and short pins 23 & 24 on the RFEngine when prompted to reset the device.
      Thanks for the response. I have tried that already and the dropdown menu for port is always empty. If I manually input USB0 it gives an error: "Unable to open the specified port".
      The event log still recognizes when I insert the dongle and it says " a SNAP USB device was Discovered" but I can not communicate with it at all. This confuses me since as I said on my post, I dont think the protoSleepCaster.py or the protoFlasher.py scripts modify any of the UART pin assignments.

      Any suggestions?

      Comment


      • #4
        protoFlasher.py doesn't do anything that should interfere with normal operation of the module - I don't think that's what you accidentally loaded on your bridge. (Quick check: is a LED on the SnapStick actually flashing?)

        If you loaded protoSleepCaster.py instead, that would explain the problem - it explicitly disconnects the serial port on startup (presumably so that no time is wasted sending out the button press report over the serial port, before it goes back to sleep).

        Acquiring a serial cable, so that you can erase the script while the module is plugged into your SN171, would certainly be the easiest and most reliable fix. There is another possibility that might work, which I am hesitant to mention since it might make matters worse - use at your own risk:
        1. From Portal's command line, do root.setup_usb_as_vcp() to reconfigure the SnapStick as a Virtual COM Port device.
        2. You may need to download new USB drivers from SiLabs to be able to talk to the device in this mode.
        3. Figure out which COM port number it ended up with - no way to predict that.
        4. You can now do Erase SNAPpy Image in Portal, since it will no longer know that this is a device that lacks a reset button - you'll have to short pins 23 & 24 to do that when needed.
        5. Finally, do root.setupSynapseUsb() to reconfigure back to normal operation.

        Comment


        • #5
          Originally posted by jasonharper View Post
          protoFlasher.py doesn't do anything that should interfere with normal operation of the module - I don't think that's what you accidentally loaded on your bridge. (Quick check: is a LED on the SnapStick actually flashing?)

          If you loaded protoSleepCaster.py instead, that would explain the problem - it explicitly disconnects the serial port on startup (presumably so that no time is wasted sending out the button press report over the serial port, before it goes back to sleep).

          Acquiring a serial cable, so that you can erase the script while the module is plugged into your SN171, would certainly be the easiest and most reliable fix. There is another possibility that might work, which I am hesitant to mention since it might make matters worse - use at your own risk:
          1. From Portal's command line, do root.setup_usb_as_vcp() to reconfigure the SnapStick as a Virtual COM Port device.
          2. You may need to download new USB drivers from SiLabs to be able to talk to the device in this mode.
          3. Figure out which COM port number it ended up with - no way to predict that.
          4. You can now do Erase SNAPpy Image in Portal, since it will no longer know that this is a device that lacks a reset button - you'll have to short pins 23 & 24 to do that when needed.
          5. Finally, do root.setupSynapseUsb() to reconfigure back to normal operation.
          The LED in the SnapStick is stuck in "amber" from the previous MCastcounter script that I was running. I am sure I loaded one with protoflasher.py and the other with the sleepcaster.py. I might have changed something else after trying to fix it.
          I'll try to use a serial cable tomorrow and if not, I will need to try your method. Now that I think about it, I also need to find a computer with a serial port. I saw the posts about the USB to serial connection being unreliable. Hopefully I can solve this problem tomorrow and start with the real work.
          Thank you for your help.

          Comment


          • #6
            @thesheriff- you should not need a true serial port to perform these operations. A USB-to-serial cable will give the functionality required to factory-default, erase the script, and/or upload new firmware.

            @jasonharper is correct that if you convert the SnapStick to look like a COM port to Windows/Linux/MacOS then you can short the pins to reset the module and start the process.

            (Side Note: Unfortunately, using a device that looks like a true "USB" to the OS, ex. Windows, is not an option. The OS cannot properly see the module's reset event.)
            sigpic
            Proven Solutions for the Internet of Things
            www.synapse-wireless.com

            Comment


            • #7
              Originally posted by thesheriff View Post
              I was surprised because the scripts as described do not seem to change the UART assigments so I suspect the issue is related to Portal not being able to talk to the devices while they are on sleep mode. Can anybody clarify this?
              By design, sleep mode is meant to put the module in very low power operation. It will not react to inputs other than those configured as "interrupt" pin.

              The ProtoSleepCaster.py script does indeed set all I/O to outputs pulled low in order to obtain the lowest sleep current levels possible. However, the push button wakes the module for a brief period of time to send out a message (i.e. the push button is tied to an interrupt pin that is configured as such in the script).

              SUGGESTED SOLUTION:
              1. Swap the modules (ie put the one on the SnapStick on the ProtoBoard and vice-versa)
              2. Connect Portal to the SnapStick with "untainted" module
              3. Optional -if you don't already have your problem-node in your list of devices: Click on the green "plus-sign" from the toolbar and manually enter the address
              4. Start an upload of good script to the sleepy device.
              5. Hit the push-button to wake the module. Portal will retry the upload several times until it sees the node wake.
              Last edited by Jheath; 10-28-2013, 08:48 AM. Reason: Clarity
              sigpic
              Proven Solutions for the Internet of Things
              www.synapse-wireless.com

              Comment


              • #8
                Originally posted by Jheath View Post
                By design, sleep mode is meant to put the module in very low power operation. It will not react to inputs other than those configured as "interrupt" pin.

                The ProtoSleepCaster.py script does indeed set all I/O to outputs pulled low in order to obtain the lowest sleep current levels possible. However, the push button wakes the module for a brief period of time to send out a message (i.e. the push button is tied to an interrupt pin that is configured as such in the script).

                SUGGESTED SOLUTION:
                1. Swap the modules (ie put the one on the SnapStick on the ProtoBoard and vice-versa)
                2. Connect Portal to the SnapStick with "untainted" module
                3. Optional -if you don't already have your problem-node in your list of devices: Click on the green "plus-sign" from the toolbar and manually enter the address
                4. Start an upload of good script to the sleepy device.
                5. Hit the push-button to wake the module. Portal will retry the upload several times until it sees the node wake.
                I manage to find a Serial to USB adaptor and it worked after a few tries. I will leave one of the RF engines untouched from now on, so I always have a spare to go back to if I need it. For some reason the rf100 that I put protoFlasher.py on was not responding either.

                For future references, what is the danger in using root.setup_usb_as_vcp() ?

                Thank you all for your help.

                Comment


                • #9
                  Originally posted by thesheriff View Post
                  For future references, what is the danger in using root.setup_usb_as_vcp() ?

                  Shouldn't be any danger. You can revert things back using the "root.setupSynapseUsb()" command.
                  sigpic
                  Proven Solutions for the Internet of Things
                  www.synapse-wireless.com

                  Comment


                  • #10
                    Originally posted by Jheath View Post
                    Shouldn't be any danger. You can revert things back using the "root.setupSynapseUsb()" command.
                    Thanks. I will try to use this setting later on when I have more rf100s to fall back if something goes south.

                    Comment

                    X