I finally got around to trying to get PPP working with a G400D and a SIM5320E modem on a custom board.
AT commands and SMS all work fine at 115200 bps with handshaking.
The issue comes down to trying to get the PPP to work. I followed the code here (with some changes to suit my seriaport setup and sending of AT commands) and I get a CONNECT 115200 prompt from the modem so I know it is connecting to the GPRS network.
https://www.ghielectronics.com/docs/30/networking#3309
It never gets past the evt.WaitOne() line in the code. I have to set a timeout in a thread to terminate the PPP connection.
It would be really handy if the PPP driver had an option to display on the debug the progress. Something we could enable or disable.
Anyone else have it working?
1 Like
I did not have it working with a custom board, but working on a Cobra II with the cellular modem.
I can say though, that I agree about the debugging features of the driver - which has been improved significantly by John in the latest release.
@ John - A debugging option would be very helpful as the setup often ends up being quite complex with the cellular stuff…
Thanks njbuch, I had a suspicion you would be looking at this. 
It needs to work with any module and not just the Cellular Module although I do have one of those and a Cobra 2 that I might hook up tomorrow and try it out.
A few debugging lines showing progress would be good or an option to enable the showing of the RX and TX bytes would be handy as I have found this to be ideal for PPP debugging on a different target in the past.
@ Dave McLaughlin - It can take a while for the PPP stack to completely initialize and be ready to use. I have sometimes seen it take two minutes between the call to netif.Connect and the events being raised. If you’ve tried waiting longer and it still won’t work, are either of the NetworkChange events raised?
We will take a look and see if there is more debug output we can send, but it is unlikely since we use the PPP driver from the lwip stack at the moment. It has some tracing of its own, but that’s only enabled for debug builds.
If I remember correctly, when I was debugging some issues when we added the PPP feature to 4.3, I would capture the TX and RX lines and feed them into Wireshark. It has a PPP analyzer I believe. It may give you some clues as to where you are getting locked up at.
@ John - Thanks for your feedback John! Rgd the lwip PPP - whats your move when the NETMF networking stack is going to be re-built?
@ njbuch - From what we can see on github, they are still using lwip, just better integrated and updated.
Thanks John,
I will solder some wires onto the board and see if I can read this with Wireshark and see if it detects anything.
I let it run for quite some time. 2 minutes is way too long.
On the Android system I use, it connects within seconds of the PPP connection being made. The handshaking with the GPRS network is pretty quick.
Hi John,
I hooked up the RX line to capture what the GPRS network is sending.
I can see something about UMTS_CHAP_SRVR in the data link but then after a very short time I get a NO CARRIER but the driver doesn’t seem to detect this.
I need to hook up a second USB to serial to capture the TX and feed this into a PPP decoder.
Here’s what I have found. It appears to be that the G400 is not receiving all of the bytes.
I have 2 USB-TTL boards connected to the TX and RX on the G400 side of the modem board. This allows me to capture the data to and from the modem.
Before I call the PPP.CONNECT I can send and receive AT commands without any loss of data. If I then do a PPP connect, I see packets back and forth in the buffer and then finally an error and the PPP driver stops. Sometimes I see a NO CARRIER and sometimes a message in the buffer about no network protocols.
I eventually timeout and then call ppp.disconnect() and ppp.close() and then I then send +++ to put the modem back into command mode and after this I no longer get any replies in the serial buffer even though I can see clearly that they are being sent by the modem as I can see them in the capture window. The BytesToRead is always zero.
I can see the AT command go to the modem and then see the reply in the other window so I know the modem responded but the G400 times out and shows no bytes in the buffer but clearly there are.
For some reason it appears that the PPP drive still has control of the received data? Is this possible?
At this point I still don’t have PPP working with this modem. I can see the handshake between the network and your driver but I think some bytes are missing on reception and this is why it fails. 
This is the raw bytes to and from the modem. I still need to process this into a PPP decoder as there are lots of 7d in there.
@ Dave McLaughlin - What SDK are you using?
Hi John, 4.3 pre-release 3
@ Dave McLaughlin - I do not think the PPP driver handles AT commands well when it is in PPP mode. So it probably discards data like “NO CARRIER”. Our handshaking takes so long due to the issues with timers in the NETMF lwip integration. The driver shouldn’t be hanging onto the port after you call disconnect, but to be sure, can you call dispose on the PPP and serial port objects and try to recreate the serial port?
I know it isn’t a final solution, but can you try PPP with our cellular modem module and your sim card? That one was the only one we had available to test when we were adding PPP.
I’ll try the changes you suggest.
As for trying the cellular module that is not possible with this board as it’s custom and no gadgeteer sockets.
The thing is that PPP should be able to work with any modem, not just the cellular module.
@ Dave McLaughlin - It should work with all modems, yes. But trying it with one that is known to work at least rules out some other possible causes.
OK. I’ll try a test on a Cobra 2 and let you know.
I’ve found in the past that it was the handshake protocol at the PPP level that was at fault. Something I recall to do with the magic number not being set correctly.
@ John. I hooked up a Cellular Module to the Cobra and ported the exact same driver and code to an existing application that I want to add PPP to.
I had issues to start with as the module is not autobaud so finally found that it runs at 19200. A bit too slow for GPRS but enough to test.
Ran the code and it connects to the network. Same SIM as I using in my custom board so same APN, user and password etc.
Mmmm. Both are SIMCOM modules. I am using the SIM5320E which has GPS and 3G but other than that the electrical interface is the same.
The SIM5320E defaults to 115200 so I decided to try setting it to 19200 and try PPP. Nothing. Still doesn’t connect. AT commands are all good.
I now need to somehow hook up the SIM900 based Cellular Module to the serial debug so I can capture the packets and see what is different.
This will take a bit of time as I will need to make up a couple of adapter boards. I’ll report back later.
By the way, the same SIM5320E modules work as I use them with my Android based data a logger connected over USB and using the SIMCOM RIL. Same power supply etc. The NETMF version is UART based.
Just to add to this. After my struggles with the G400HDR I finally got it working with the cellular modem too so this confirms that the G400-D is OK too. At least at 19200.
Just need now to somehow capture the packet data to find out why the SIM5320E won’t connect to GPRS.
@ Dave McLaughlin - or we can test the SIM5320E for you
Very possible Gus as I really need this to work.
Let me check the costs to ship a board to you and I will need to make up a connection for it as it is designed to plug into my custom board and requires +7 to +24V to power it.
