Im writing application that communicate (via serial port) with electronic device which i designed myself.
When my PC application starts - it opens available COM ports one by one and it sends some string ("What are you?" for example).
My device is programmed, to reply to that "magic question" with own ID (for example: "I am evil device for supervising employees").
When my PC software receive that "magic reply" it starts working normally and its not searching other ports anymore.
Of course im not using stupid questions in data transmission, its just example.
Question is - can i send strings like on all (not busy) ports, to discover my device?
If I can - how that "question" string should look? Are there any normalized standards?
This is not first project like this on my desk, but now im developing solution for little industry and i need to pay more attention what my application is doing, because there may be other devices connected to COM ports and I do not know how they can react.
Im sorry, if i made some language mistakes, english is my third language.
Thanks in advance for replies.
After Alvin Wong confirmed my concerns I thought about it again and redesigned my device discovery functionality, because I don't want to abandon that idea.
I will send unique-complicated-ID every 1-5 seconds from device.
When my PC starts - it will try to open sequentially all available ports and will listen for that ID for few seconds.
If application receive that ID - it will be confirmation, that port number/name is correct and I my connection is established.
No, you wouldn't want to do that.
When you are using COM serial port, you have no idea what is plugged into the port. It could be nothing, your device, a modem, a mouse (though I believe nobody uses this anymore...) or whatever you can't even imagine.
Imagine if it is connected to another computer (probably a Linux/router), sending things may lead to execution of "that command", thus creating unexpected effects (though your program may not notice). Or if it is some badly-programmed device, it may trigger a bug in the firmware, thus failing the device and making it malfunction.
In short, in the worst case, you can cause a catastrophic event.
Serial (RS232 or UART I assume) communications don't have a designated transfer protocol (in contrast to USB which has one) to identify a device, so it isn't fail-safe. The user must make sure he selected the correct port. This is probably one of the reasons why hardware manufacturers choose USB, and one of the reasons why USB is so popular, even to computer idiots.
Related
I am involved in a project where we have some kind of IoT device. An nxp processor with an LTE modem on a PCB. The software running on it connects to the modem over a single uart interface. It will initialize the modem through AT commands, and finally made a data call to the provider (PPP).
Then, it uses lwIP (light weight IP) to open some mqtt subscriptions, and allow user code to make http get/post requests to our servers.
Every 15 minutes we want to retrieve signal strength from the modem and report this back to the server. What I do now, is put the modem back in command mode, retrieve the signal strength info, go back to data mode, and resume normal operation.
The round trip from data mode, to commando mode, and back to data mode takes several seconds (4-5 ish). This is annoying, because during that time we are not receptive for commands.
I've read about gsm mux 07.10. By following some defined protocol it allows to create virtual serial ports, over one physical uart. That sounds nice, although I realize this will go at the cost of performance (bytes will be added to each frame we send to either command mode / data mode).
The gsm mux 07.10 spec dates from 1999. I am far from an expert in mobile solutions. I was wondering: is muxing still the way to go? How does a typical smart phone deals with this for example? Do they include modems with more than one uart to have parallel access to AT commands and a live internet connection? Or do they in fact still rely on gsm mux?
If somebody would be so kind to give some insights. Also on potential C libraries that are available that implement gsm mux 07.10? It seems that TinyGSM implements it (although I can't seem to find where), and I also can find the linux kernel driver that implements gsm mux 07.10. But that driver is written on top the tty interfaces in linux, so that would mean I would have to reverse engineer the kernel driver and strip out the tty stuff and replace it with my own uart implementation.
First of all, the spec numbering is the old GSM specification numbering, so those old specs will never be updated, the new specifications with new numbering scheme will. I do not remember when the switch was made, but I do remember someone at work giving a presentation on 07.10 probably around 1998/1999, so probably a few years after that or around that time (and definitely before 2009).
The newer spec numbering scheme uses three digits for the first part.
So for instance the old AT command spec 07.07 is now 27.007, and the current 07.10 multiplex specification is 27.010.
The following is what I remember of 07.10.
The motivations for developing 07.10 was to exactly support the kind of scenario that you describe. Remember back in the mid 90's, if mobile phones had a serial interface then that was RS-232 though each manufacturer's proprietary connector at the bottom of the phone. One single serial interface.
However, in order to use 07.10 mux in serial communication you needed to install some specific serial drivers in Windows with support for 07.10 (and I think maybe there was some reliability issue with them?), and for that reason 07.10 never took of and became anything more than an rarely used solution.
Also by the end of the 90's additional serial interfaces like Bluetooth and IrDA became available on many phones, and later USB as well, which both added additional physical interfaces as well as natively multiplexing within each protocol.
So the need for multiplexing over physical RS-232 became less of an issue, and whatever little popularity 07.10 ever had dwindled down to virtual nothing.
Fast forward a couple of decades and suddenly someone asks about it on stackoverflow. Good on you :) As far as I can tell I cannot see any fundamental problems with using it for the purpose you present.
Modern smart phones that support AT commands will most likely have a code base for the AT command parsing with roots in the 90's, which most likely include the AT+CMUX command. Of course manufacturers today have zero explicit wish for supporting it, but when it is already present it will just come along with the collection of all other legacy AT commands that they support.
So if the modem supports AT+CMUX you should be good to go. I have no experience or recommendation with regards to client protocol libraries.
Can we broadcast Music using wifi broadcast and listen to thhe same on devices supporting monitor mode.
I would like to listen on monitor mode because I expect the number of devices getting connected is too high for wifi to work properly using IP-protocol.
I want the wifi device to act as a FM broadcast where every device recieves every packets and stream the music.
Are you talking about this Wifibroadcast , here?
If so: well yes, monitor mode is the underlying technology, as can be seen here.
Now, if this is about doing a commercial product, sadly, you cannot expect any kind of interoperability from this.
Streaming audio/video over Wi-Fi is a business, and the the power in charge (Wi-Fi Alliance aka WFA) as some view on it, including certification programs. Have a look at Miracast, using Wi-Fi Direct.
As for multicast / broadcast, it is even more of a business and the realm of proprietary technologies for now (example here - and no, this is not limited to automobile). This is quite complicated, to start with because of the synchronization problem across receivers: you don't want 2 radio receivers in the same room to play with a 1 seconds delay, this would be cacophony.
EDIT:
Meaning, be it with the Wifibroadcast OSS project or with the proprietary industry about it, since there is not yet an open protocol for this (as "publicly available standard specification", I don't even go about implementation, FLOSS or not), you will have to provide a specific application for every receiver to match your broadcaster protocol, and vice versa. And that is the state of the industry today. That is what the company I mentioned above, or this other one more well know, or these are doing. And so, they do not interoperate. This will be your problem: provide a receiver app for Windows, Mac OS, Android and iOS (where you may not even have access to sub-layer 3 API) that will match your radio broadcaster protocol. And Linux too, please.
Though, this is the direction of history because this is what the user wants: stream A/V to/from device/application X from brand A to device/application Y from brand B.
And so people have been working on this, on layer 2, because layer 3 and above have unsolvable challenges with it, at IEEE since 2004 with Ethernet AVB, which is a set of protocols. You can download some of its standards for free, others for a moderate fee depending on how old they are. There is a SIG taking care of certification(http://avnu.org/certified-products/) to guarantee interoperability.
It is for 802.3 (aka wired Ethernet), but there is some work done to bring this to 802.11 Wi-Fi. Because again, that's what the user wants, the market is here, no question about that. It will take a long time. Even more to get consumer electronic grade devices or applications of the shelves. But they will interoperate out of the box, that's the goal.
There's even been work done on moving this to layer 3/IP as well BTW, with some performance sacrifice.
So come back in a few years, and all should be setup. Or, if you have lots of time and money and no urge to deliver, implement a solution based on these standards?
PS:
Link to AVnu (Ethernet AVB SIG) page about use cases for consumer electronics audio streaming, wired or wireless:
http://avnu.org/consumer/
...and its 10 pages white paper at the bottom of the page.
There's a old piece of software we run in our company that manages RFID cards tapping in/out to open doors.
We want to create an app who identifies who just touched in on a specific place (we have the id for that) and grab their 1st name, to say "Hi [NAME]" on a screen.
As I mentioned, the software is quite old and there are no APIs. It communicates with the RFID hardware via a serial port (COM1).
I was wondering if the best way to get the data I need is to somehow intercept the COM1 traffic and extract/look for the data I want.
Does this sound like the best way to go about it? Would it work, or would it be impossible to get names and numbers from the data being transferred?
Cheers,
Andre
Can you configure the software to use a port other than COM1, or configure the hardware so it's physical serial port is assigned to a different COM port?
If so, take a look at com0com. It's a Windows driver that creates two COM ports on your PC with a virtual NULL modem between them. Data going in on one side comes out on the other.
Here's how you'll set things up:
RFID Reader connected to physical COM port (COMx)
your program bridging COMx to COMy and sniffing the traffic
com0com linking COMy (for your program) to virtual COM1 (for the legacy software)
legacy software
You'll need to write a program to pass data between COMx and COMy while monitoring it for the information you're looking for. Make it simple yet robust, since if it goes down you're reader will stop working.
A Simpler Solution
If you only need to monitor one side of the communications, create a cable that connects the GND and RX pin of COM1 to another COM port. Now your program can monitor that side of the conversation, without interfering with the legacy software.
Well, generally, you can look at RS232 signals, if that's the way you want to do it. It's tricky because you need to "sniff" the signals, which means buying or making a rig that allows the original signals to go through, and then gives you a way to attach to them as well. And, you need to send the transmit and the receive signals to TWO serial ports (on the RX lines). Then you'll probably want to get some "sniffing" software that allows you to look at what you're getting in time sequence (ideally, with time-stamps). Some cutesy protocols also will use modem lines, so you may need to monitor those as well.
Or, try searching for "free serial port monitor" or "serial sniffer".
Good luck!
I would like to use a GSM modem to make a voice call to a phone number, play a recorded message, wait for a digit to be pressed and then disconnect the call. The system needs to know if the line was busy, if the user answered and which digit was pressed by user (if any). It should drop the line if nothing is pressed in 30 seconds. If user presses the digit before the question is completed then the voice should stop (user doesn't have to wait). Also, it would be nice if system could handle invalid digits (play "invalid digit" message, play original message and wait for input). Multiple calls in parallel would be nice, but I guess this is not possible?
I have found this article which explains low-level interface quite nicely. However, this question is more pragmatic - which libraries and which GSM modem would you recommend? OS is Linux, modem can be either RS232 or USB. I would prefer Python, but C(++) is ok too.
BTW: this is not telemarketing, it is a notification system. Not that it matters... ;)
EDIT: I learned this system is known by keyword "IVR" (added for future searchers).
A modem is generally used for data transmission but it sounds like you are actually transmitting voice, albeit prerecorded voice, and tones.
Although you can achieve this with the extra voice capability of a voice modem as you have identified, it might actually be easier to use a GSM to VoIP gateway, unless you actually need the modems data capability for some reason.
You could connect the VoIP to GSM gateway to a low cost or free open source PABX (such as Asterisk) and use this to build your particular application.
Some gateways even support multiple SIMS so you can target the SIM which gives the lowest call rate for the number you are calling - for example if you know that the number you want to call is on a particular operator, then that operator may offer free 'on network' calls between it's SIMs. This might be an advantage if you are expecting to make a large number of calls.
If you do a web search for 'VoIP GSM gateways' you will find some examples.
The following link provides an overview also:
http://www.voip-info.org/wiki/view/VOIP+GSM+Gateways
I am no expert in this field but it is something of a personal project that I have wanted to dive into.
Here is what I think will be the best way to do this.
1 Get yourself a VOIP GSM Gateway like this: VOIP+GSM+Gateways
2 Link into an existing PABX system or download a free one like asterisk
Then you will need to follow the instructions of the PABX development to create your dial plans and routing. I don't know if there are any already out there but I'm sure you will find many examples of the bits and pieces you need.
I remember years ago my friend and i were playing command and conquer red alert and there was a mode were we put the others phone number and the game would dial up and connect. What was this called? and where can i find resource to program for this?
Dial-up Networking perhaps. You will have to learn how to control the modem. I remember there were some commands that looked like this: ATH0++ which was how you could make the modem do different things. Perhaps that will give you something to search for.
This resource looks kind of helpful: http://www.activexperts.com/activcomport/tutorials/modem/
One issue you might find is that there are two types of modems generally. One is an actual modem which is connected to your serial port. The other is what is typically known as a "winmodem" which is usually in a PCI slot and didn't have all of the functionality on the hardware but instead used the hardware drivers which typically only worked in Windows. MODEM stands for "MOdulator DEModulator" which means it just converts a digital signal to analog and vice versa.
In essence, it seems that if you can figure out how to program to the serial/com ports on your computer, you should be able to access the modem.
Another interesting link: http://en.wikibooks.org/wiki/Serial_Programming:Modems_and_AT_Commands
Have a look at TAPI (Telephony API). In Windows world there is a set of APIs in the OS for this (http://msdn.microsoft.com/en-us/library/ms737219(VS.85).aspx). The AT command set (Hayes commands) can also be used without TAPI in Windows if you treat your Modem as a COM port and send AT commands to that COM port (that's what actually TAPI does) but it isolates you from their different variants and also running initialization and other commands in a particular order.