I just posted SIM800H IoT Module on Creations. Feel free to discuss and make suggestions here.
7 Likes
Are you planning a gadgeteer or click module for This?
@ Bec a Fuel - Yep interesting that there is a click with one of the SIM800 chips on it as well, and no Gadgeteer module with the SIM800.
I understand that the drivers by @ JSimoes are closed source, and the drivers for the Fona is open. So I guess its just rolling up the sleeves.
I have just (last week) received one of each of the Adafruit modules (800L, 808, 900 and 5320E) and I am updating the Fona drivers to add SSL and work across all of these models. Once that is done, an Azure IoT layer will come. The drivers work with netmf, .net and mono and will predominately remain open source (I say predominately, because I have a commercial sponsor and it will be up to them to decide the disposition of the bits they are sponsoring).
1 Like
@ njbuch - the PCB has castellation pins that are very easy to solder. If there is enough interest from the community we could come up with a Gadgeteer board.
@ mcalsyn - you can find my implementation of the .NETMF HTTP client for Azure IoT on the GitHub repository. It’s now part of the official SDK:
(AMQP is on the way 
)
3 Likes
@ JSimoes - Excellent - nicely done.
@ njbuch - if you don’t mind me asking: what are you concerns with the driver code being close source?
Don’t get me wrong: I’m all for open source and I personally contribute to several projects, but sometimes, that is not aligned with a particular commercial policy or something else…
1 Like
@ JSimoes - We at the Mikrobusnet.org team are still looking for ways to ensure a good quality driver for one of the GSM click boards, so far the challenge has not been taken by any of us, but the best to happen was a shared code-base for a commonly used chip, like the sim800. I guess that some of your work might fit into that category, and also a lot of the mcalsyn work would fit there.
Optimally, building a click-driver would be 1 hour of work at most.
@ JSimoes - Very nice work. Any plans for a 3G module?
I see a lot of SIM 900 and 800 series modules out there. Unfortunately cellular support for the 800/900 modules here in the USA will not be very good in the next few years. AT&T will finish sun-setting their 2G service in January 2017. T-Mobile will continue to support it until 2019.
@ skeller - thanks! 
No immediate plans for a 3G… 2G will be around for a little while I guess.
3G and 4G modules for “simple” M2M are expensive and I believe that we’ll be seeing alternative offers for M2M from network operators in a near future.
1 Like
Going through that just now with a US client. He has one of my older QUAD band modems and although it works, it’s a bit temperamental in regards to connecting to GPRS with AT&T and we will deploy to the field this week so fingers crossed we get a signal out there otherwise we will have to switch to the newer module below.
For this reason I developed the SIM5320E (or A version for the US) module that offers quad band and 3G for not much more than the SIM800/900 cost.
I am just waiting patiently for GHI to release the latest SDK that fixes the PPP issue with anything other than the SIM900 and then I will have a working 3G system for GPRS data. Right now I am using SMS and this works reliably.
Is hardware handshaking a “must” ?
I see rts cts documented on [url]http://eclo.github.io/SIM800h-IoT-module/[/url]
But in configuration only the COM and a power pin is passed?
public static void Configure(
OutputPort powerKey,
SerialPort serialPort
)
@ David@ Leclanche it’s highly dependent on what the code is doing. For regular initialization, sending/receiving SMS and module management the hardware handshake is not mandatory. Now if the code is a heavy user of sockets and HTTP requests that generate a lot of quick and possibly large amounts of data on the UART then the handshake is highly advisable, otherwise you may end up losing stuff.
Regarding the call to the Configure(…) method apparently missing any mention to RTS/CTS that is on purpose. You just need to pass the “resources” it will use (serial port and GPIO pin). All the UART settings and other configurations are handled internally by Configure, so the caller doesn’t have to worry about it or the specifics of the implementation.
I only have UART4 left on my G120 based boards :think:
Looks like XON/XOFF is possible but “should not” be used for binary data…
[url]http://simcom.ee/documents/SIM800x/SIM800%20Series_Serial%20Port_Application%20Note_V1.01.pdf[/url] (Page 12)
And yes i need this connection to download the IFU hex files…
Looks like XON/XOFF is possible but “should not” be used for binary data…
That is correct and the reason for the driver to use hardware handshake.
And yes i need this connection to download the IFU hex files…
That would go into the heavy UART usage category, I guess… If the mcu and the code can handle the response stream fast enough you can probably get away without flow control. Or you can implement your own “delivery” protocol to send the IFU files in data batches that are small enough for the UART buffer don’t overrun.