We have managed to get the PPP connection established from an older Embedded master basic development board with upgraded firmware.
The problem comes in with the 3rd tcp connection we try to establish. Basically we establish the PPP link, create tcp/connection send some data and then close it. Do nothing for 60 seconds and then send again. The problem is the third connect attempt never succeeds. It simply blocks for a long time and always fails. A few minutes later, there seems to be no timeout setting for it.
The first 2 attempts work perfectly. I have even reduced the time to 30 second intervals between sends and the results are the same.
Any help will be welcome. The GC lists, which makes me wonder if there is a leak somewhere?
[quote]1) The PPP connection is established and left open.
2) Just left it for like 10 minutes and it just hangs, no timeout or exception. Just hangs.[/quote]
Do you check NetworkChange.NetworkAvailabilityChanged event handler in your application? the ISP might be terminating the PPP connection because it is idle for long time.
Add this to your code:
NetworkChange.NetworkAvailabilityChanged += new NetworkAvailabilityChangedEventHandler(NetworkChange_NetworkAvailabilityChanged);
static void NetworkChange_NetworkAvailabilityChanged(object sender, NetworkAvailabilityEventArgs e)
{
if (e.IsAvailable)
{
if (PPP.IsLinkConnected)
{
Debug.Print("PPP connection was established!");
}
}
else
{
if (!PPP.IsLinkConnected)
{
Debug.Print("PPP connection was dropped or disconnected!");
network_is_read = false;
}
}
}
[quote]3) Everything happens on the same thread, we noticed that handing objects from thread to thread doesn’t always work so well.
[/quote]
There are some ways in .NET on how to handle object access through multiple threads, such as “lock” statment.
Thanks,I am familiar with multi threading and locks, in this case I have avoided threads due to issues experienced in the past. But nonetheless. I do indeed check the network availability and it doesn’t change.
The device simply seems to hang. I also figured that the modem goes into sleep mode. But it doesn’t seem to be doing that, nor does it appear to be the ISP. Next step I guess is spying on the comms between the Ublox modem and the EM.
I’ll try some rapid connects and disconnects tomorrow to get a better feel of what is going on.
I hope the next version of MF .NET will contain better timeout and error reporting. I have added a piece of code to detect the dead connection and then force a hard restart but it is a really ugly way of working.
One of our customers had a similar problem with Ublox modem. the modem just freezes and never responds till your reset it. We will test this kind of modems soon.
But I would like to make this clear. PPP communication has no connectivity check mechanism. So PPP will not see any error if the modem is not responding or if it freezes, actually the modem should not freeze.
I don’t see a reasonable way of sending a timeout or exception to the user application if that happened.
Usually higher level protocols such as TCP has this mechanism and it raises exception when the TCP connection is lost.
[quote]I hope the next version of MF .NET will contain better timeout and error reporting. I have added a piece of code to detect the dead connection and then force a hard restart but it is a really ugly way of working.
[/quote]
Probably this is the best way to handle this case, since the modem is not responding, the PPP connection will still be on (from EMX side) because it did not get the termination message from the ISP/modem, and it can not guess by itself that the ISP/modem is not responding and decide to timeout or terminate the connection.
Thanks, will re read the UBLOX docs and contact our ublox representative. Can you speak to your customer about what they did to overcome the problem?
On PPP I get that PPP only facilitates TCP. What is needed is a way to control the timeout on this level when trying to establish a connection.
Anyway, at this stage we have to be careful not to blame a specific component yet. What is certain is that I cannot talk to the server on the otherside. possible problem areas could be the GSM/GPRS network, unlikely but possible as we have a similar solution running beautifully on that exact same network.
Then the UBLOX modem. Then finally something with PPP or the way the PPP setup was accomplished.
Thanks, we are keen to help as we have already done a design and test boards for the ublox. We have been in touch with our ublox supplier and have a few plans to get a better feel of where the problem might be.
Time is not really on our side here but every little detail will matter. I don’t think we are far off. It must be something simple.
We have done some more testing and will be upgrading the firmware of the ublox module as it is a development kit. Like almost all development kits the modules and kits don’t have the latest firmware.
The ublox modem has a setting to turn off power saving. We did turn it off in the past but it didn’t have an effect until we moved it to the front of the AT command queue. Voila. It now seems to work more without losing connection after a while. (We have not tested this to death yet, but we suddenly can connect and reconnect for 10 minutes or so without hassles)
We homed in the problem by opening and closing a connection every 500ms then we gradually increased the sleep time between attempts.
We are not entirely convinced that we have solved the issue but it may be that when the ublox want to go to sleep it sends back some commands that may upset PPP or it simply just goes to sleep. Our ublox representative did inform us that there were changes on the particular ublox module in terms of sleeping.
Our engineer came across another potential problem with clock drifting and synching between Embedded master and Ublox. We will investigate further. In our application it must be able to run 24/7.
I do find that the TCP/IP socket.Connect that don’t timeout to be a big problem. I have built in a module reset to force a restart but nonetheless it is a very harsh way to deal with a reality, and that is that connect attempts will fail more often than desired.
Thanks for the help. Something else to note is that like all other GPRS modems the UBLOX start up sequence seems to be very finiky.
Firmware upgrades are evil, Firmware upgrades are evil… set us back another day. Upgraded ublox firmware. Turned out not to be such a clever idea. The modem is at least talking to us after a day’s worth of tinkering. But only up to the point where you need to start preparing it for GPRS.
Previously the +++ call followed by the ATH worked. Must be a reason for it. Will worry about it again tomorrow.
Have you had problems with UARTs failing on EMX boards? We went from Embedded master to EMX with LCD. Bad move it seems. The second EMX board seems to work fine. Both EMX’s have almost identical hardware layouts.
We used the Embedded master to talk to the Ublox initially then we upgraded the firmware and switched to an EMX design we used for many other projects.
Took us several hours to start homing in on of the problems and it seems totally hardware related. If we tie the EMX modules TX and RX pair together as loopback it works but as soon as we connect it to the ublox no luck. It sends ok but the data coming back from the ublox is garbled. We used a USB to uart (FT232) and could talk to the ublox no problem. Just the return data to the emx that created a lot of issues. (Garbled response)
At one stage we postulated that we are transmitting at one baud rate say 115200 and device is responding at another baudrate.
Eventually replaced the EMX with another module and the problem went away.
Our next challenge seems to be firmware related the +++ problem with establishing a GPRS connection.
In our application it must be able to run 24/7.