Hi Folks,
doesn’t know much about all this Gadgeteers stuff, but as far as I see, the Cellular Radio Modul Needs socket K but the G400HDR didn’t have a socket K ???
Is there any trick, or is it real that I can’t connect this two moduls, which would be strange.
With best regards
Gerhard
As far as I remember, Cellular radio was a KU module (there was a mistake on silkscreen of early versions or something). So you may try U socket.
@ Simon,
thanks, but the difference between K and U is the flow control capabillity, and I didn’t know, if the Cellular Radio Module needs it. Schematics of the module show this signals, but no idea they were used by the driver or not.
As I am in the phase of setting up the project, I have to decide which (serial) port I can use or have to use for which purpose, so it would be very helpful to see at the various documents, which lines were needed/used.
But with the help of the AutoDirection feature of the RS485 chips, I can use the one UART for the Cellular Radio, hope the drivers can easily configured to what ever serial controller.
As I have to made my own board, I cant use the Gadgeteer moduls, just for a quick prototyping, this moduls may of some help.
Thanks for the Input.
@ andre.m, as you see, I have to make my own board, so I just try to find out, what the driver need and than will try to wire the board as close as possible to the Gadgeteer moduls to avoid intens driver adapting.
With best regards
Gerhard
If you are only using SMS then there is no need for RTS and CTS with the GSM module.
I have used the SIM900 many times without handshaking and even with PPP at 57600 and it worked fine (Not with GHI as there is still a firmware issue above 19200 on the G120, G400 and ChipworkX that I have tested this on)
I am planning on working on the GSM driver but I am snowed under with another project just now.
Hi Dave,
hmm, bad news.
Want to use G400D and need a web page for monitoring and configuration the system, but only cellular radio is there, no cable.
I also need to send data attached to emails.
So 19200 is quite slow. But if there is a firmware problem, it must be to the UART driver, so maybe it can be rewritten using RLP.
Or, GHI folks, is there a chance to fix that issue?
With best regards
Gerhard
It’s noted by Gus here Andre. They need to add DMA to handle the UART to get the faster speeds working without overruns.
https://www.ghielectronics.com/community/forum/topic?id=13036&page=5
John at GHI already confirmed what I had found out about the UART interrupt handling and he found that the devices do not have a FIFO and that the receive character register was getting overwritten because the interrupt handler is not processing the input fast enough.
Hi Gerhard, you sure get the interesting projects to build 
Interesting point about the RLP idea. I might look into this. It all depends on how fast the interrupt handler will be processed to determine if I can read the bytes out fast enough. Any latency more than the byte time will fail.
By the way, getting a web server to work over GSM has 2 issues you should consider.
1 is that the current 4.2 firmware does not support PPP so attaching your sockets to the GSM modem will require you to write a driver for this. Most GSM modems have AT commands to allow a remote connection to a TCP/IP socket and you can then send and receive the data. I have not been able to get this working well at 19200. It needs to use high speeds.
Sending emails or connecting to a server will work if you can get it to work at the lower baud rates and have some way of hooking up the AT commands for TCP/IP into a driver of some sort.
Hi Dave,
currently we use an industrial computer board running XP. The same problem, but all ready to use. You need an account at dyndns (www.dyndns.org) and run a dyndns client. Each time the ip adress changes (with a new connection) this client reports the new ip address to dyndns and this sevice maintains a list to translate a name (which is always the same) to the current ip address. Works for some stations over the last ten years without any problem.
In the meantime I found an implementation of such a client in MF, so this is more or less solved. Maybe there is a bug in it, but nothing that can’t be solved I guess.
I am not familar with the deep layers of Internet (for now). Did the data connection of this Cellular Radio send data packages of same size, or is this data of dynamic length?
Guess it is same size, it would be easy (and industrial standard) to implement a ring buffer, which can hold some such packages. The background fills this buffer using the DMA ontroller which is a masterpiece from Atmel compared to impementation of other companies. You can pump data in at very high speeds without disturbing the CPU.
The foreground is running a thread (the web server) which takes this packages out of the ring buffer and do what ever needed.
The cellular Radio moduls also implement Start/Stop in hardware using RTS/CTS and software, XON/XOFF, even if the buffer gets full, there will be no problem.
Processing it character by character in a ISR is a very simple implementation.
If the data is of dynamic length, things going little more tricky. But buffering is still possible.
And this works the same other way round. The chip has more than one DMA layer, so simultaniously sending and receiving of data packets could be done all in HW and so really fast, as we have a 400MHz machine.
So I hope it is possible to get this running more or less.
Find more Infos at Smart | Connected | Secure | Microchip Technology page 447 ff.
With best regards
Gerhard
Hi Gerhard,
That works fine with systems connected to an ISP as you generally get a STATIC IP (even though you are dynamically allocated this by the DHCP server) and so this is visible on the internet to any machine. With a simple setup on the router, you can direct port 80 and 443 to your web server within the network.
The issue with GSM is that the IP address you get back from the network is not visible outside the network. You are given a private IP that is behind their NAT.
You might be lucky with your GSM operator but it can’t be assumed that all will work like this. Here in Indonesia they have 4 main operators and only 1 has visible IP’s.
Hi Dave,
there is no router.
The system is out far off civilication and monitors environmental parameters, sometimes it at a mountain, not reachable for month cause of the snow there.
It is powered by photo voltaic and fuel cells.
So we cant and want not put a router there.
The system is directly connected by cellular radio and this works fine over the last few years, thanks of dyndns.org.
If the ISPs strats to give us private net addresses beheind their NAT we will run into problems, but uptil now, there is no known issue with that here (Austria, Italy France, where the systems currently installed).
With best regards
Gerhard
The router was only in reference to a network setup at home or in an office. You are right, not needed with the GSM.
You are lucky with your GSM operators and the fact you receive an IP that is visible from the outside world. As I said, of the 4 here, only 1 has this capability. It’s why my remote systems have the embedded system make the connection to the server and poll the data via Modbus. This works very well. I can use this to control the motor speed and start and stop it.
Good luck with your project. I hope the serial overruns don’t become an issue for you as they have for me?
We have run into this problem a couple of years ago in projects for several large clients, and as a result developed the [em]Yaler[/em] relay service, that I’ve also used for the server examples in my book [em]Getting Started with the Internet of Things[/em]. Basically, Yaler uses an outgoing connection to a public relay server, to enable tunneling of incoming connections to a device. So physically, the connection is outgoing, but logically, it is incoming.
If in the future you are faced with an operator where your current solution does not work anymore, you may want to take a look at http://www.yaler.net
Cuno
thanks for that info …
I only want to run a simple web page and send attachments via email, hope I get it running and hope I can give some Input to overcome this issue.
Cause G400D is quite perfect to be a member of ‘InternetOfThings’, but therefore the TCP/IP connection has to work properly.
With best regards
Gerhard
PS: Were you are located?
@ Cuno. Looks interesting. I have other designs that might benefit from this.
The only thing I couldn’t find on that website was pricing. It references Pay-Per-Use on the front page but I could not find any pricing for the service. Before I sign up to try it, I would like to know what the costs would be.
Cheers.
In Zurich, Switzerland.
Best regards
Cuno
Is this your business?
Yes, I’m a founder. And I also work at Oberon (Cuno’s company). Kind regards, Thomas
You are aware that there is currently no PPP support for the G400D yet? This means there is no simple way to connect the GPRS stream from the GSM modem to the TCP/IP networking in the G400D.
Most modern modems support TCP/IP through AT commands but I have not seen any that support a listening socket. They all appear to be initiating only.
Very nice. Good job in your work. We are working on something similar but it is good to see ready options.