Unable to send broadcast

[james]

I am getting a message when Portal first tries to connect stating "Unable to send broadcast requesting device status". Everything worked fine yesterday but today Portal is not communicating with any of the nodes. I have a good USB connection to the bridge device but it does not show up in Portal. I have tried rebooting and powering everything on and off and nothing so far fixes it. Any clues?

[mgenti]

That particular message indicates that we have tried to send a broadcast PING over the packet serial link but never received an acknowledgment. There are few reasons this could be occurring. First, this could happen if you have changed the UART that is connected to packet serial in your script. Also, if the module that you have in the USB board has it's default UART set to 1 which is the RS-232 on the evaluation boards. Is Portal able to see the nodes if you connect to the same board via RS-232?

[james]

I have not modified any of the scripts and everything was working fine thru the USB interface yesterday when I left. I can try the RS232 cable but I'm more suspicious of a board problem.

[mgenti]

Please let us know when you have a chance if it works via RS-232. Also, what version of Portal and SNAP are you running?

[kbanks]

This one is unlikely but I have seen people tripped up by it... have you turned your "bridge" node off and back on? Sometimes people do this, and don't realize that Portal automatically disconnects from USB nodes when they are powered down. You have to tell Portal to reconnect after you power the node back up.

The same type of thing applies if you have left the node powered up, but you have physically unplugged the USB cable. After you reconnect the USB cable, you must tell Portal to reconnect.

Even more unlikely, but worth mentioning for completeness - Sometimes people are tripped up by the "external power" LED on the board. It does not mean the board is on, it just means the board has external power connected. Take one second to verify the on/off switch is in the "on" position.

[james]

Good points, but already been thru all of that. One thing I do notice is when I power the board off and back on, I get the usual USB disconnect and reconnect on the PC. The bridge device on power-up displays 00 on the LED display ( I'm running the McastCounter script). When I then do a New Configuration ( getting the previously mentioned error again ), the LED on the bridge device now displays a single 0 - not sure if this is an error message, but thought it might be worth mentioning. I will have to install Portal on another machine to get access to an RS232 port but I will try that. Also, I am running version 2.0.31 of Portal.

[james]

OK, I'm confident my bridge device has gone south. I changed over to an RS232 connection on another PC and tried to connect to the bridge device without success BUT I then connected thru RS232 to the photo device and it is recognized and works. I then tried connecting thru the USB device on the bridge board from the second PC and got the same results ( Unable to send...) so all indications are the bridge device is not working properly. I am local so I can come swap it out if that works for you.

[kbanks]

Since you are so close, feel free to come on by, but here are some more things to try:

1) Using the OTHER board as your gateway (you already said this is working for you), can you communicate with the first board OVER THE AIR?

2) If you can, you should be able to verify the Configuration Parameters "remotely", fixing them up as needed.

3) Alternatively, now that you DO have a PC with a serial port, you can try using the Erase Snappy Script function (look under options). This might restore access.

4) If Erase Snappy Script does not help, try Reset To Factory Defaults (also under Options).

5) Finally, try Upgrade Firmware (also under Options).

Steps 3-5 all require you to be connected to the board over RS-232. Also, steps 4 and 5 (if successful) will leave the board configured to talk RS-232, not USB. You would still need to change your config settings (or reload script McastCounter.py) to restore the USB port as the active interface.

[james]

I was able to use the photo board as the gateway and connect to the bridge device but it is very flaky. As soon as I powered on and clicked "New Configuration", the bridge showed up but then the next time I did the same thing it did not show up. There is some intermittent behavior associated with the bridge board. During the brief time I did have a connection, I was able to reflash the script but this made no difference. At this point, I'll just come by and exchange the bridge device.

[kbanks]

Kevin, Mark, David or Brent. One of us will get you fixed up.

[james]

Thanks, I'll come by Monday.

[kbanks]

Thanks for stopping by this morning, sorry I missed you. Brent gave me your bad module so I could run additional tests on it. It appears your radio chip died. (The processor and serial interfaces are fine, I can control the module from Portal, as long as I do not try to use the radio).

[agriffis]

I am having the same problem, perhaps for different reasons. I upgraded / installed PortalPro 2.0.31 (upgrade from PortalLite) and then hooked up the usb cable to the same base module that was working well in PortalLite. I agreed to the firmware update from V1 to V2, and after connecting the RS232 I was able to continue. It stalled half way through (maybe some flash problems?) and 90% way through a couple of times, but eventually I got it to update the firmware.

When I ping from RS232 I can see the device NODE1 ok, but not from USB. And NODE2, while on and operable, is not visible from either USB or RS232 connections to NODE1. I did upgrade NODE2 to V2 via RS232 and can get a response from it with Ping, but I don't see NODE1 from there via Ping either.

Finally, NODE1 seems to need to be upgraded from V1 to V2 about every time I power up. This is the second time it's been flashed (upgraded one rev of V1 f/w a while back). I wouldn't think the flash would be expired yet, but maybe the filesystem is full? I did erase the NODE1 device and reset its nonvolatile to factory defaults, assuming those don't collide with V2 (since it was V1 the last time it was at the factory).

Your thoughts?

[agriffis]

I saw at the bottom that you found a bad radio and I had one extra rf module in hand so I hooked up NODE3 to the RS232, reflashed the device with V2 f/w and then reconnected. NODE2 showed up in the ping.

So I guess I have a bad radio on NODE1. Is there a diagnostic on the NODE1 cpu that would have told me that? some sort of power amp measurement or such?

[mgenti]

When I ping from RS232 I can see the device NODE1 ok, but not from USB. And NODE2, while on and operable, is not visible from either USB or RS232 connections to NODE1. I did upgrade NODE2 to V2 via RS232 and can get a response from it with Ping, but I don't see NODE1 from there via Ping either.

Can you verify that NODE2, NODE3, and NODE1 all have the same channel and network ID? This information is displayed in the node Info pannel after clicking on a node in the list.

[kbanks]

When I ping from RS232 I can see the device NODE1 ok, but not from USB.

When you upgrade the firmware in a unit, any SNAPpy script that may have been in the unit previously is erased. If it was your previous script that was configuring the node to talk over USB, you will have to reload that script (possibly over the air) to switch back over to the USB port.

And NODE2, while on and operable, is not visible from either USB or RS232 connections to NODE1. I did upgrade NODE2 to V2 via RS232 and can get a response from it with Ping, but I don't see NODE1 from there via Ping either.

I think Mark is on the right track on this one (see his previous post). This sounds like nodes are not configured for the same channel and/or network ID.

Finally, NODE1 seems to need to be upgraded from V1 to V2 about every time I power up. This is the second time it's been flashed (upgraded one rev of V1 f/w a while back). I wouldn't think the flash would be expired yet, but maybe the filesystem is full?

There is no "filesystem" in use here, we treat the FLASH as a block. Once a unit has been re-flashed with new firmware, the old firmware is gone. So, I have no guess at all why it would look like your unit was "reverting" to older firmware (unless the upgrade process is in fact not working, and it really is staying at the old rev).