NetBurner Community Forum

We have a real problem here. The SBL2e netburners will not pass serial data through to the ethernet IP destination and port when first powered on. You always have to go into the netburner with a web browser and hit the "submit new settings" button to get it to start passing serial data. This happens every time. We are not loading any new settings, just the page full of correct settings that we know work. But immediately after resubmitting the old page again with the "submit new settings" button, the data shows up in the target application as expected.

We will not be able to operate like this in the fielded application.
We expect to have the users power up the serial device and the netburner and have the dataput out by the serial device to immediately start flowing to the computer (after a reasonable netburner boot up period). It should not be necessary for a human to intervene by talking to the netburner with a web browser and pretend to change a setting in order to get the data to begin flowing.

Note that after we do this one time after each power up, the serial data flow behaves normally.

Submit a support request with the configuration info.

How the board is configured.
The software version number.

The IP addresses of the device and the server its trying to attach to.

Are you using the device DNS name or the IP Address to connect to.

As much info as you have.

If your DHCP is slow its possible that the device is trying to send too soon, thus waiting for the retry time interval before attempting to connect again.

If you let it sit for a bit does it eventually conect?

[quote="pbreed"]
>Submit a support request with the configuration info.
I'm unsure how to initiate a "support request".

>How the board is configured.
The overall system consists of 4 radio modems with serial output driving 4 netburners cabled via a network switch to a linux box running 4 instances of Intercepttty to create virtual serial ports.
This is because the application used to run on hardware with multiple real serial ports.

The application runs successfully using a multiport comtrol devicemaster pro device server. But we want to migrate to netburners for size, temperature spec and cost reasons.
The radios we're connecting to have a main data port 115k,8,1,n RTS/CTS.
Also a setup port tx,rx only at 19,200. We're wired to Netburner port 0 for the main data port and port 1 for the setup port. Serial settings match device settings as above. We can telnet into the radio's setup port via netburner port #1 with the common IP port 23 no problem.
The issues are with port 0 of the netburner interface with the radio's main data port.

Fixed IP address 10.51.10.93 (for example) on netburner
Port 0 settings:
Never make outgoing
9036 target port
10.51.10.23 target machine
UDP
default packetization.

>The software version number.
Most of our testing used 1.54 the factory load.
We have tried 1.59 and believe it doesn't work at all.
We just tried 1.58 and it seems to work with outward symptoms same as 1.54
(see below)

>The IP addresses of the device and the server its trying to attach to.

See above. The software consuming the serial data runs on a linux box with IP address 10.51.10.23 and looks
for data on port 9006, 9016, 9026 and 9036 from the 4 netburners on the test network.

>Are you using the device DNS name or the IP Address to connect to.
Fixed IP addresses all around.

>As much info as you have.
If we power up at a time when no serial data is being presented to any Netburner,
the network seems to come up as we had hoped. Then when the 4 radios start hearing messages they seem to get properly packetized by the netburners and arrive at the destination ports OK.
We are running multiple instances of intercepttty on a linux box to process the data with a
software application that was designed to work with multiple virtual serial ports.

However, if someone power cycles one of the units [radio/netburner pair] while over the air transmissions are occuring (i.e. serial data being presented to the netburner while it is booting up) then something hangs and no data from that unit will ever show up back at the linux box.

We have tried all possible combinations of handshaking on the netburner and on the radio with the same result. We have, however, discovered that if we go in to the web setup page "serial page" handshaking setting and change the CTS to NONE on netburner port 0 hit accept and then change it back to CTS and hit accept a second time, then data will flow. Only this particular sequence of "double whammy" will get the serial data flowing. It takes changing the setting and then changing it back to snap the interface out of its hang state.

Needless to say, we can not have a human operator having to execute this double setup operation in the deployed system as it will have at least 10 radios streaming data by way of 10 netburners that will be miles away. We cannot require a fixed power up sequence either because the units will be in different locations and subject to different electrical power interruptions.

We have tried 1.54, 1.58 (appear the same) . Tried and 1.59 can not be made to pass any data
no matter what kind of "accept" whammy tricks we try.


>If your DHCP is slow its possible that the device is trying to send too soon, thus waiting for the retry time interval before attempting to connect again.

>If you let it sit for a bit does it eventually conect?
We are using UDP and not TCP. We are not using DHCP so the above questions do not appear to apply.

We would like someone to take a look at the firmware. We believe the serial port needs some kind of a reset AFTER the netburner completes its bootup sequence or the port needs to be blocked during the bootup sequence that is not happening currently.

Any help or ideas will be greatly appreciated.

To submit a support request ticket go to the Netburner home page. Across the top are black bold text items that are actually menus. Hover over the one named Support and then mouse down to the item named Support Login. Log in with your name and password. On the page shown after log in click the button on the left for New Ticket. If you don't have an account, use the New User button on the login screen to create one.

Its always easiest for me to break a problem down to a simpler form. Thats what the support guys will probably ask you to do as well, otherwise I don't know how anyone could make any progress on this. What happens if:
- Just one SBL2e
- Just one computer, windows or linux
- Run a serial terminal on the PC
- Run a UDP program (my dev kit has a netburner utility) to send packets to the SBL2e.
- What shows up in the serial terminal window?

Now if the behavior you see in the complex system is repeatable, you can run wireshark to capture the exchange and the problem can be more easily identified.

You definitely should not need a reset for each data exchange.

gerald lucha wrote:
However, if someone power cycles one of the units [radio/netburner pair] while over the air transmissions are occuring (i.e. serial data being presented to the netburner while it is booting up) then something hangs and no data from that unit will ever show up back at the linux box.

Just a suggestion, if the Boot Port is still set to the default COM0, after the Netburner powers up it sends out its startup prompt message which will be seen by the radio, and until the 2 second Boot time has elapsed, any serial data coming in to COM0 will be seen by the boot monitor as commands, and can cause NetBurner to misbehave.
You might try changing the Netburner Boot Port from COM0 to COM1, and also try using the Netburner's Quiet Boot mode (which prevents Netburner sending prompt string out Boot Port). If you know the radio's setup port will not be sending as you power up, this should help.

If the radio's setup port can also send during the Netburner boot, you can do some h/w to lock out the incoming data to the Netburner during the Bootup.

Roland,
Thank you for the suggestions. It sounds like it would help to change the boot port but I have no idea how to do this.
I do not recall seeing it on any of the web setup screens.
Can you point me in the right direction to make such a change?
Also, we will certainly want to try this 'quiet boot mode' that you suggested.
But, again, I don't see a control that would activate it.
Gerald

There are a couple of ways to enable quiet boot. BTW, this is the kind of thing you can easily search for on the wiki, where you'll find an entry in the FAQ on enabling quiet boot. (When you use the search box at the top of the forum it searches both the Wiki and this forum). In addition to what the FAQ mentions, the IP Setup application has an Advanced Settings button. If you click that you will see a checkbox for Boot Quietly.

Thanks Tod, and thank you for your patience. I had seen that there was a wiki but did not know which of the several methods would have the best chance of containing the answers. We'll immediately try advanced setup and all of the new possibilities presented by that. It is a bit embarrassing because I now remember using that button in ipsetup early on and then got in the habit of more simple usage. I completely forgot the advanced settings. Knowing that search will search both places is good news too. Thanks again.
Jerry