Adafruit Fona
Moskog
Posts: 554
For long distance communication between two Propellers I purcased two Fona breakout boards, because this boards should be capable to do anything! For testing I use two Parallax professional boards and connect the Fonas directly to their own PC's through the serial-usb part of the boards (not using Propeller). I'm using the PuTTy as terminal because that support a wider use of special keycombinations (like control-Z).
The setup works fine for testing, like sending SMS through the GSM network.
But I do not plan to use SMS, I rather would like to make an online connection between the two Fonas, send data and receive data.
The problem is I can't seem to find any information anywhere on how to do make such kind of comunication. Not even to set the Fona into Data mode. SMS, phonecalls and that stuff is well documented, even FM receiving!!
So if anyone here can give me an idea on how to start, what supported AT-commands I need to make a connection, that would be great.
For the simpliest test I need to call the other terminal, make a connection and then write on one terminal and see the text appear on the "remote" terminal, then write back.
After learning how things work I plan to write the spin code for the Propellers.
The setup works fine for testing, like sending SMS through the GSM network.
But I do not plan to use SMS, I rather would like to make an online connection between the two Fonas, send data and receive data.
The problem is I can't seem to find any information anywhere on how to do make such kind of comunication. Not even to set the Fona into Data mode. SMS, phonecalls and that stuff is well documented, even FM receiving!!
So if anyone here can give me an idea on how to start, what supported AT-commands I need to make a connection, that would be great.
For the simpliest test I need to call the other terminal, make a connection and then write on one terminal and see the text appear on the "remote" terminal, then write back.
After learning how things work I plan to write the spin code for the Propellers.
Comments
I may be out of touch but the last time I did this kind of thing it was from an embedded system running Linux using a good old GPRS phone module. It went like this:
1) Do some chatting with the module over the serial line, sending AT commands to configure the thing and make a connection. This was done using the Linux "chat" command.
2) Then use the point to point protocol to exchange IP packets over the serial line and hence establish TCP/IP connections to whatever you want. This was done using the Linux "ppp" command.
I cannot see the Propeller running PPP any time soon. Never mind the IP stack on top of that.
Or...have they now built all that TCP/IP stuff into things like the Fona? In which case I would expect Adafruit to have documentation. They are generally very good at such things.
If not you may have to put something like a Raspberry Pi in between the Propeller and the Fona to make the connections for you.
Oh, and it's almost certainly not possible to connect from from one Fona to another through the mobile network. Even if you get them to get them on an IP network they will have private IP addresses so it's impossible for a client on one to see a server on the other.
So how did that work?
Basically you were using AT commands to your modem to get it to make a normal voice call to another phone.
The modem at the other end would answer the call.
Then you send serial data to your modem. Which it uses to modulate tones sent over the voice connection. At the other end the modem demodulates the tones back into a serial bit stream. Hence "modem", modulator/demodulator. Hence also the slow speed and that familiar screeching noise modems make.
Before the days of Hayes modems that understood AT commands one would have to make the call manually first. Then get the modem to screech down the line. Via an acoustic coupler.
Now, I guess it possible to get your Fona to dial a regular phone number. But someone has to answer at the other end.
Then you need to be able to input and output audio to it.
If you can do that with your module then someone here has made exactly the modulator/demodulator for the Propeller you need. Sorry I forget who it was or what it was called. Search the forum for "bell modem"
All this is far away from modern IP based network communications.
PPP or SLIP would be running as additional layer on this but you can just do plain ASCII chats over it or talk to a getty process awaiting your (plaintext) login like in good old BBS days...
The fine manual really looks like nostalgy... ;-)
I know that Adafruit has a FONA product that includes the Sim808, but it isn't clear that this is the one that you have.
There is no need to use a PC... a single Prop is fully capable of talking to two phones at one time using AT commands... and then you can monitor the communication with a single Propeller Terminal. Control-z would be something like: ser.tx(26)
Without GPS or Bluetooth, prices start around $5. I have been very pleased with them.
If you want Bluetooth and GPS (Sim808) it costs a bit more. I have found that the more expensive models(non-AdaFruit) aren't as described and have had best luck with the cheapest... amazingly:)
I have no clue about actually using data mode. After looking very briefly at the AT command docs, I think the SimCom modules will do all of the heavy lifting and simply report the results... probably encoded, but possibly using the text option, which makes everything human readable. This would make parsing the data on your end a breeze. Probably the main trick is to get the module configured correctly.
If you figure it out, please post the results.
Interesting.
What I'm looking for is a kind of list of what has to be done to be able to Deal number, Establish connection, Exchange data, and then Close the connection.
So far it seems I can do most of it except for the Exchange data part.
My two Fonas use the chip SIM800L and SIM800H. Its hard to find any information on this issue.
How much data? Over what distance? What is the time constraint for the exchange?
I looked around and found this general discussion. Which contains a pretty good description of the process... (no code examples there). AFAIK Adafruit has all official documents on the Sim80x series.
I don't have time to try it. FWIW: I think trying to do it manually is going to be somewhat frustrating... lots of typing, lots of stuff to remember to do; much easier to do it programmatically.
Its about just a few bytes, one propeller calling the other to get some environmental data, distance over the GSM network should probably be irrelevant.
The discussion thread you mention mostly show how easy threads are drifting away from the original subject, but the thread starter seems to have the same idea as me except that he wants to transfer files.
I been playing a lot with data exchange between Propellers, using radio modems on 144MHz, I guess it's very similar using a GSM modem too. My problem is to initialize the GSM modem (In this case the Fona) to be ready for data transmission.
I've played with the Fona a bit.
The various AT commands are of course listed in the datasheet but I found it difficult to understand the proper syntax of these commands.
I found it very helpful to monitor the communication between an Arduino and a Fona. This allowed me to see examples of the command syntax being used correctly.
Here's a link to the thread where I described my efforts to communicate with the Fona.
In the above linked thread, I posted some example output of my "MonitorFona" object. As the data is sent to the terminal, the source of the data is identified using one of four prefixes. These prefixes allow one to see which device sent the data.
As I mentioned earlier, I found this output very useful when trying to understand how the various commands were supposed to be used.
Besides the "MonitorFona" object, I also wrote a simple serial bridge object to allow one to communicate with the Fona using Parallax Serial Terminal.exe. There's a link to the serial bridge object near the end of the thread (here's the link again).
From the AT manual [url="file:///C:/Users/brick/AppData/Local/Microsoft/Windows/INetCache/IE/0VC3LTZ9/SIM800_Series_AT_Command_Manual_V1.05.pdf"]v1.05[/url]
you enter the data mode using AT+CGDATA... this has only one protocol supported, which is "ppp"... which means that you are going through
another network to transfer your data... which means that the time constraint is going to be largely uncontrolled. IF you need something close to real time... then I think something like XBee serial is the way to go.
To me the choice to use data mode rather than simply use SMS adds complexity and unknowns, but won't improve the final result. I have used XBee for serial control and found it to be very easy and there is a lot of support here, if you get into trouble.
My example linked above shows how to use a remote Propeller/Phone to monitor incoming sms from a master prop/phone, pick out the relevant messages, parse those messages, and respond to them. In my example: on request from the master, the remote SIM80x gets GPS data, stores it to a uSD card and sends it along in an SMS to the master phone. The remote phone can also be told(via SMS) to send a continuous stream at a pre-programmed interval, which could be made variable.
The data could easily be any sensor data (which could also be roughly time stamped).
The whole cabutal can be automated... and a notification scheme could be added to handle out of range data.
Along the lines that Duane is discussing. I found [url="file:///C:/Users/brick/AppData/Local/Microsoft/Windows/INetCache/IE/0VC3LTZ9/SIM800_Series_AT_Command_Manual_V1.05.pdf"]this
[/url] about setting up tcp/ip code on an Arduino Mega.
This is still an option of course. With the FONA you do have the mic and speaker all hooked up. What you could do is encode your signals using bursts to the microphone... output from the Propeller, used to configure the bursts any way you want. On the other end, you would monitor the speaker with a Propeller and decode the messages.
The simplest way would end up working like a telegraph:) It would be near real time. You wouldn't need to set up another network and you could forget about AT command sequences:)
I found out I can not use semicolon (;) when dealing the number, without this, both Fona's get into Data mode when connected. For my test I used the Putty serial terminal at 9600 Baud, I also tried Parallax Serial terminal but had lots of problems with executing some of the commands. (Probably due to some wrong settings, maybe.)
Both Fonas need to respond with OK after the command AT to be sure they are ready.
ATD[phonenumber] to make a call (or ATDL to redeal last number used)
RING appears on remote terminal, answer with typing ATA. (Tried auto answer command but got Error)
CONNECT 9600 appears on both terminals after a few seconds if successful connection.
Now anything typed on both terminals appears on the remote terminal. Was not able to get the echo work here, but that's not a big deal, Propeller won't need echo.
To close the connection: a pause one second, then +++ and another one second pause (no problem when manually typing) -to get back to Command mode, then
ATH to hang up. No message on terminals, like telling No Carrier after this command, but both the Fonas really hang up.
So it seems things will work this way, probably much better with a microcontroller too.
rjo_ your idea on using mic and speaker lines is really not a bad idea either, could still be a solution.
My general idea is a remote vending kiosk that I can periodically ask about things like inventory, transactions, and machine health.
So once a day or so, I call (or surf) into the thing, and it replies by sending a (and this is where I am stuck) data stream or a csv file or...
Inasmuch as getting it configured, I have made a DAT table of the literal strings I culled from the (thick) manual. If I need another variant of the same command, I make another unique literal. This way I can just call it by name and wait for the OK. Here is the list of commands I currently send it to get it set up. I chose volatile settings where applicable since it gets reconfigured at bootup anyway.
And here is my current list of predefined (by me) commands.
To have FONA send a text message:
gsm.str(@txtTestPhoneNumber) 'text mode pause(250) gsm.str(String("This is a test SMS message.")) gsm.tx(26) 'Send the message via CTL+Z gsm.tx(13)It boots great, never seems to send errors, and I can send it a text message and have it reply with a text message, but I really need to further digest the manual. Dry stuff.
I have thought about sending transactional information in text messages, but am having some reservations about overall reliability of using that approach. I would LOVE it if I could figure out how to have it update a web page so I could just save it as a favorite.
I have a logic analyzer, and have been considering getting a working Arduino to monitor the TxRx lines, but I could also use a Propeller for that. I saw that someone on this forum has done exactly that.
If I get anywhere, I'll post up what I come up with.
Since IoT is such a hot topic, it would be nice if there was a subforum dedicated to the subject.
IMHO the strengths of the FONA products are in the engineering, user base and documentation. You can see what you are ordering and are pretty damned sure that is what you will be getting. I am not an engineer, so I don't know how much can be reliably done to encode the audio signal, but done correctly it would be secure and as real-time as you can probably get.
I'm not a big fan of iot... too open, too inviting. If it were me, given that kind of choice, I would prefer a text based solution ... every time. You can obscure and encode text messages til your heart is content:)
If I can monitor the moisture in the soil of my house plants and garden from the other side of the planet that is good.
If I can command my irrigation setup to deliver more or less water that is even better. Saves annoying friends and neighbors with calls asking them to take care of it.
I agree that human readable text based messages are preferable over some kind of binary encoded gunk. Makes creating and debugging the whole system much easier.
But, having obscure text messages is basically the same as using ciphers.
One often hears the phrases like "Security through obscurity is no security"
Which is kind of true, your message formats and whatever algorithms you use to mangle them won't save you.
Better to concentrate the obscurity into those keys that only your system knows. And use well analysed cipher systems that everyone knows about.
It wasn't that difficult transferring data between the two Fona GSM modules. I have two Prop Professional test boards each with one Fona module. "Remote" and "Home". Remote calls Home, then the two exchange welcome messages. Then Home sends a data string containing updated time codes and other things up to Remote. The Remote replies with its collected weather data back to Home, before they both close the connection.
I plan to place the Remote module in my cabin, about one hour away from here, to send home weather condition data, batt voltages, bird-feeder status and other stuff every six hours or so.
But before I start making the PCB's I would like to hear your opinions on using the Fona with the necessary Lipo battery. Adafruit says there is no way to use the Fona without the battery. Because of voltage spikes up to one Amp or so. When googling Lipo I see batteries like that are very sensitive and can start burn or even explode almost without any good reason. "Do not charge without attention". So now I'm very concern on using this module, with the recommended battery (1500 to 2000mAh.)
Maybe I should trash the Fona and better buy another kind of GSM-module, or should I get rid of the batteries and try to make another supply instead? Anyone here that has tried the module with another power supply, super cap or something, into the Batt connector?
I have seen a number of Lithium Ion batteries that are a little safer but still require some attention. The 18650 is very popular battery.
It looks like the fona can charge the battery so you should be fine as it will monitor and keep the battery charged.
Mike