Sudden failure in data collection / positioning system

[morehouse94]

I am designing a system that collects temperature data and does very basic positioning by monitoring the link quality between nodes. The broad strokes are:

• I'm using RF266 modules for my nodes
  
• Sensors are I2C, I have reassigned my I2C clock pin to be the Data In pin and my I2C data pin to be the Data Out pin
  
• At every second, the mobile node checks the temperature sensor output and calculates temperature, uses an RPC/callback to determine the link quality between it and the other nodes, and then reports this information to Portal by plotting and printing the data.

When I run this, everything goes swimmingly for a while (sometimes for 30 minutes, sometimes for a few hours) and then I suddenly start getting errors reported regarding my RPC for getLq(),indicating that I am getting a "None" value instead of an integer from the getLq().

Shortly after a couple of these errors pile up, everything goes screwy. Data stops getting reported altogether and I am unable to update my nodes over the air. When I connect the RF266 to my computer (via an XBEE explorer dongle from Sparkfun) it is unable to function even as a bridge node and I must erase the SNAPpy image to get it to work again. Sometimes after erasing the image, the RF266 is still totally unresponsive (making me the owner now of several non-functioning radios).

My questions are these:

1. Any ideas as to what could be causing this seemingly randomly occurring error?
   
2. How might I restore my unresponsive RF266's to working condition?

Thanks in advance to anyone who can help!

[Jheath]

My questions are these:

1. Any ideas as to what could be causing this seemingly randomly occurring error?
   
2. How might I restore my unresponsive RF266's to working condition?

Sounds like you've already used the "erase image" tool under the Options menu in Portal to erase the script over the serial port.

Using the same setup, you can first attempt to factory default things. This will reset any SNAPpy level items that might be re-purposing the UART, changing channel, etc...

If this does not appear to work then you can once again use the same setup (just a serial connection to your PC) to re-flash the core OS/Firmware.

In Portal...

1) Connect you RF module to a PC running Portal via serial port (UART1 => which is the case if you are using the XBee board)
2) Under the "Options" menu select "Firmware Upgrade..." or "Factory Default NV Params"
3) Reboot the module and Portal will automatically start the process

[morehouse94]

Thanks for the quick response! When I got home, I followed your instructions and I'm afraid the problem persists. Portal claims that upgrading the firmware was successful, as was restoring factory NV parameters and erasing the image, but when I go to connect the RF266 through the COM port afterwards, it still does not recognize that a module is there. I observed Portal doesn't prompt me to reset the module before erasing the image as it normally would, and the RSSI LED is illuminated, which it normally is not. Does this help point to what the issue may be?

[jasonharper]

Wild guess: is your script constantly calling saveNvParam(), perhaps in your 1-second hook?

[morehouse94]

Thanks, Jason, but I haven't included anything about NV params in my script.

Here is the section of my code with the 1 second hook

def loc():
    global Lq1
    global Lq2
    rpc(SN1, 'callback', 'assignLq1', 'getLq')
    rpc(SN2, 'callback', 'assignLq2', 'getLq')
    rpc('\x00\x00\x01', "Lq_comp", Lq1, Lq2)        
    
### REPORTING ###   
def report_temp():
    rpc("\x00\x00\x01", "read_temp")
    
def print_temp():
    rpc("\x00\x00\x01", "print_temp")
    
def report():
    loc()
    print_temp()
    
def plot():
    report_temp()

    
count = 0
@setHook(HOOK_1S)
def minute_report():
    plot()
        
    global count
    if count == 59:
        report()
        count = 0
    else:
        count += 1

I know that leaves out the definitions of some of the functions I am calling, but I can tell you that the plotting (i.e. report) functions and print functions are just doing an RPC to Portal telling it to plot and print the data being sent.

[morehouse94]

Here is an update that may help to troubleshoot:

• Shortly after my reply to Jheath, I plugged the module in question back in and the RSSI light was off. I know now that the RF266 doesn't have an "RSSI" pin (that's an XBEE thing apparently) and the pin in question is pin 6 which corresponds to "IO_20, PWM Output, Interrupt." All of the sudden, the thing was actually able to reset and I successfully erased the image and can now communicate with it.

However, I still have two other unresponsive RF266's and they are displaying very different behaviors:

• Module #2 does not respond to the reset button and therefore can not be reached to erase the image, reset NVparams, or upgrade firmware. Even using a wire to manually pull the reset pin to ground doesn't work. As a side note, connecting the wire between certain pins and the 3.3V power causes portal to return with "Did not receive hello message" (not sure if that is helpful info).
  
• Module #3 does respond to the reset button, and Portal reports that both erasing the image and returning NV params to default were successful. However, the module is still not recognized when I try to connect to it via the COM port. Interestingly, when I try to upgrade the firmware, I receive the error message "Unit was unable to change block address"

Thank you very much for those who have replied and to anyone who might have an idea of more tests to run or ways I could get these modules back up and running. This one is quite the puzzle.

[gvoce]

How are you powering these devices? If the reset does not work then that indicates that Portal did not see the reset which is done via a serial connection. There is only one UART on this device so there is no chance of changing the default UART. What type of serial cable are you using? I assume it is a USB to serial adapter ??