We are running a course in robotics and Xbee is the most favorite communication protocol for the student. In last two years we helped them build around 62 various projects (40 more in pipeline).
All most all the projects involve sending different kind of data to the bot. Sometimes it is a 1 byte command where as sometimes it is a long string to be interpreted. Sometimes we face the issue of addressing a bot when one xbee is used in broadcast mode to send messages to a particular bot among several. Students use their creativity to address this issue each time.
I personally feel this is reinvesting the wheel. I wonder if any higher level protocol proposals exist for serial port communication and if there isn't any specific protocol design I wonder if if the worth designing one for the student needs.
Do you mean internal only protocol of your system? If yes, often embedded software engineers incline to roll their own protocols. Most of them talks that it lets them make most optimal system.
It is not ideal approach. I agree with you that it's good for students to learn good examples.
Unfortunately I don't know any protocol stack fitting well robotics application. But I advice you to try google's protocol buffer system, its able to simplify most efforts of building protocols engines, and it works with plain c too.
You can implement Modbus ASCII if you want to go with a standard protocol that's already open.
Comli is a master/slave protocol that is used in some older devices or when it is not possible to use ethernet. You can probably get the specification from ABB if you ask - it's no secret.
That said you can put an OPC server/client architecture on top of that to get a bit more powerful communication e.g.
+--------------+ +--------------+ +--------+
| OPC UA Client| -- | OPC UA Server| -comli- | Device |
+--------------+ +--------------+ +--------+
This would make your OPC UA client protocol indepedent which makes things a bit easier down the road.
Modbus is another serial protocol that is used a lot
I believe OPC will give you the highlevel operation that you want.
see
www.opcfoundation.org
www.abb.com
PS. OPC UA is not the same as the old OLE version and thus has nothing to do with COM/DCOM
Like mjh2007 said, Modbus is standard, open and easy. The only problem I can see is if you want the robot to respond "quickly" to a command, since serial Modbus uses timeouts to detect the end of a packet. You can get around this by ignoring the timeout requirements and calculating the expected size of a packet based on it's function code and parameters as you are receiving it, then you can start processing the command immediately upon receiving the last byte and verifying any checksums. This page has some more details on implementing such a scheme.
Be sure to make use of the XBee module's "Transmit Explicit" frame (type 0x11) running in API mode with ATAO set to 1. You can unicast to a particular bot on your network, instead of always broadcasting frames. On a mesh ZigBee network, you want to avoid broadcasts as much as possible.
I'm guessing you're either using "AT mode" for sending raw data, or using "API mode" with ATAO set to 0 (sometimes referred to as "transparent serial").
If you look at that frame type (0x11), you'll see that the recipient gets an 0x91 frame that contains multiple fields already (source/destination endpoint, cluster, profile ID). You can re-purpose those fields since you're not trying to do ZigBee networking.
Related
I am implementing a TURN server specifically for WebRTC usage and have some questions regarding not supporting certain attributes (send an error response if the attribute is received) or simply ignore them or other doubts. Here they are:
EVEN-PORT If my SDP always signals a=rtcp-mux, will this attribute ever be used? And if so, would it be an error if it appears?
RESERVATION-TOKEN Does this play any role when TURN server is used in the WebRTC context?
SOFTWARE As in STUN, can this be safely ignored without any processing?
DONT-FRAGMENT Is there a preferred and well-accepted norm for this attribute in the WebRTC context?
What is the ideal length of NONCE in the WebRTC context?
Different issue. Are there any statistics available for use of TURN server for transports other than UDP? I am thinking of supporting only UDP for now.
webrtc typically requires rtcp-mux, at least in chrome so I would not care about even-port.
no
yes. It is FYI only.
no. WebRTC implementations typically don't do path-mtu discovery but assume 1200 bytes.
You mean the expiration? https://medium.com/confrere/gone-in-1100-seconds-hunting-bugs-on-the-edge-of-webrtc-132a186c45dd
see https://medium.com/the-making-of-whereby/what-kind-of-turn-server-is-being-used-d67dbfc2ff5d
In my current scenario, I'm using NETLIGHT Pin (Pin no. 64) of SIM800 module with my PIC microcontroller to know whether my module is registered or not?
This way I built the circuit. Just I removed LED from VBAT. Then I connect collected of NPN transistor to pic micro input PIN.
I want to know whether any easy way using AT commands to find network registration status of SIM800?
Unfortunalty it's seem not to be really possible (or in fact detecting this state in only one way)
I use SIM800 and let it run for hours and I have seen many cases of network loose, while the AT+CREG? continue telling everything is OK.
Also, even with network down, the SIM800 continue sending you the name of the operator and the strengh of the signal.
The only way I've found is to monitor the serial port: when the SIM800 loose the network, it sends two messages:
+PDP: DEACT and
+SAPBR 1: DEACT
I suggest you to have a look at the document "SIM800 Series_AT Command Manual" and especially the chapter "19.3 Summary of Unsolicited Result Codes". You'll find +PDP and other interesting code (like under-voltage warning, DNS failed...) and see some of these messages are not linked to AT command.
From the manufacturer's documentation:
I have here a unit of King Pigeon S275 Remote Terminal Unit..
this RTU has communication modules for GSM, GPRS and TCP/IP (via RJ45 connection)
I can also communicate with this RTU by connecting it to my computer via USB .
The Manual I uploaded in this link...
https://www.mediafire.com/?gnfzfz5l7pess1p
This RTU can be configured using a configurator Software that is included in the purchase. By using that configurator software, you can also see the data/readings of all sensors connected to it, you can also see the status of all Digital Input/contacts connected to the RTU...
I have been researching about MODBUS the past days and I would like to create my own MODBUS program so that the S275 RTU can also send the sensors' data, or all the I/O data to my own program....
However ... I still do not know where I can start ...
Can I make this Modbus Program
1. using VB?
2. using PHP?
What other parameters do I need to know ?
and tutorials for making this modbus software...
I also uploaded here the S275's;
1. GPRS Custom Protocol
2. MODBUS TCP Handshake Communication Protocol
3. Register Address
https://www.mediafire.com/?khnfu53a4p12nrd
Thanks
PHP and ModBus sounds challenging. You want to control a serial port via PHP.
The easiest way is to get/purchase a library for ModBus/RTU.
Otherwise you have to implement the whole protocol by yourself from http://www.modbus.org/specs.php
You can use nmodbus API to add how reference in your VB or C# project.
There you have the manual.
Supports serial ASCII, serial RTU, serial over USB ASCII, serial over USB RTU, TCP, and UDP protocols.
These kinds of RTU’s are pretty inexpensive which means your greatest cost will be the time you will spend developing and debugging a driver. With that in mind I would first check if the RTU comes with its own OPC Server. Implementing an OPC client in C# or vb.net is very straight forward with plenty of code example out there. Some examples can be found here:
https://opcfoundation.org/developer-tools/developer-kits-unified-architecture/-net-stack-and-sample-applications/
If the RTU does not come with its own OPC server then, you can purchase a Modbus OPC Server from $900 to $2000 which will still be much more cost effective than writing and debugging your own driver and tends to be easier to setup. It will also significantly reduce the time to deliver your solution to your end customer which will be important if keep to project schedule is critical. I would check out, https://www.kepware.com/ and http://www.matrikonopc.com/
The other advantage of OPC is that it is a standardized interface which means should the RTU be replaced with a different model that supports a different protocol you would only have to purchase a new OPC server without the need to update your source code.
If the RTU does not have an OPC server or spending up to $2000 also not an option then there is plenty of open source implementations of the Modbus protocol, however implementation tends to be a bit more complex.
No problem, I used PHPModBus in several projects and it works like a charm!
This library supports Modbus TCP and UDP.
Try it, it is quite easy and straightforward.
I'm using a TK102 GPS localizer. Along with it, I got only simple end-user docs. No API, dev specs or similar for writing code that will use this localizer.
I was told that it uses UDP. So I wrote a simple PHP listener. But either localizer is not using UDP or something is wrong in communication between it and server. Listener works fine (gets UDP packets from other clients) and localizer is sending something (I'm being charge by GSM operator for GPRS transmission), but the data it sends, doesn't reach server.
I asked about server or networking issues on Unix/Linux and SuperUser. Here I would only ask, if someone knows any API/dev-specs for this localizer, so I can check, if it really uses UDP or if I haven't made any other error (in configuration for example).
The localizer and its clones
We're talking about Xexun TK102 Tracker here. The original one, because there are many clones under other companies from China, selling similar GPS localizer, with the same cover and logo, but with:
less performance electronics on-board (for example -- able to report location once per 20 or 30 seconds, not once per 5 seconds like in original one),
the ones that are sending lesser information (lack of direction/bearing, altitude, number of satelites used for location fix and many more),
units using different format of data or non-standard transmission protocol for sending it (for example, cheaper units are unable to use UDP protocol and are transmiting data through TCP protocol, using packets that not always follows standards or definictions.
Coban and Kintech are only two of many clones sold on eBay and in e-shops, claiming to be original Xexun trackers.
On the other hand, original Xexun and some clones (like Coban for example) are harder to control from own script, because they require a correct answer from the server, where data is sent over GPRS. If unit does not receive such reply, it breaks connection. The cheapes unit does not have this checking and will always sent location data to specified IP address over provided port.
Product description
Here is product description of original Xexun localizer (and here is a clone under Kintech name).
Possible buyer must be very careful (and should secure return policy, for which buying directly in China is not recommended) as there are many reports about sellers claiming to sell original Xexun device and sending a clone actually.
Though this device is five years old, it is still sold at many places (including eBay), but even at theses sources it is very hard to get anything worth for developers, except some simple, very basic user guide.
I have confirmed information (from two different sources) that there is no official API available for this device. The only option is to Google around, ask other users or use forums (see below).
If you own original Xexun localizer, you may try to contact company international departament and ask their technicians to include some changes to device source code and to send you updated firmware, with your changes - wow! That was confirmed by company itself.
Forum
I found a perfect forum for TK102 device, with a lot of questions and answers:
here is a general forum on TK102 device (kept alive for 4,5 year with 171 pages and 2000+ posts!),
here you'll find more specific topic on receiving data from this localizer,
this forum is also about TK102 unit, but it is entirely in French.
There are many other devices dissussed and in general, this is the biggest forum in the world, with topics for localizers and simillar information.
GPRS Protocol Specs
In general, any TK102 related devices is opening a socket for a direct TCP transmission (original one can be switched to use UDP protocol). Data is being transsmited over port specified by user, in configuration and using GPRS only (requires SIM card with enabled GPRS, there is no way to use WiFi).
Sending frequency, format and amount of data being send, entirely depends on kind of device is being used -- it is more extensive and more configurable in original one than in clones.
Using FileDropper I shared GPRS Protocol Specification for TK102 Geolocalizer. It contains basic information on how to setup TK102 (and possible all its clones) to send location over GPRS. And what sort of data you should except to receive from in, on server side. This could be useful for someone.
BTW: If links goes dead, contact me for a reupload or sending it over e-mail
Correct server response problem
Make sure, if you're using correct data transmission protocol! Many (really many) cheap clones uses TCP, while only original TK102 allows switching to UDP. This is convenient, because you need really basic server configuration to handle TCP connections, while you have to use specific server-side software (like node.js) or specific configuration (open to certain ports) to handle UDP. But the key thing is to determine correct protocol, as listening to TCP data, while your localizer sends UDP, will most certainly fail.
Take into consideration, that many TK102 clones requires a correct response from the server after each data, it send. It breaks connection after sending some welcome garbage UDP packet, as it does not receive response, it waits for.
It is quite hard (quite impossible?) to find any guide to many of these clones, on what kind of responses server should sent. This often leads into situation of developer being unable to estabilish two-way communication between server and localizer. Many localizers are sold to be used only via SMS communication or throughs paid services that had signed and agreement with producer and received protocol specification that contains valid responses server should generate for particular TK102 clone.
Double check, if this is not source of problem, if you can't communiacte with your localizer from your app.
You can check some models protocol specs here:
http://www.traccar.org/docs/protocol.jsp
I'm building an Objective-C app that has both a server and a client. The client can send updates to the server, and the server needs to be able to send updates to each connected client. I've been thinking about how best to implement this system, but am asking for your suggestions.
Currently, I'm thinking that when new updates are available, the server will use threads to send the update to each client in turn. If a client times out, they are disconnected.
I have very little networking experience, so am asking your insight.
Do you think that this system would work well?
If so, do you have any suggestions about how to do the threading? Any NS classes you can point me at? There's got to be some kind of queue I can use, I'm thinking.
Any other thoughts?
EDIT: I do not expect the client count to get much above 50 or so, at the max.
As long as both client and server are OS X apps and can both be written in Objective-C using the Cocoa frameworks, I would highly recommend you take a look at the Distributed Objects (DO) technology in Cocoa. I won't try to give a tutorial in Distributed Objects here, just explain why it might be useful...
DO handles asynchronous network details for you (all your client updates could happen on a single thread). In addition the semantics of communication with a remote object (client to server or visa versa; DO is bidirectional once the connection is established) are very similar to in-process communication. In other words, once you have a reference to the remote object (really an NSDistantObject which acts as a proxy to the object on the other end of the connection), your client code can send messages to the remote object as if it were local:
[remoteServer update:client];
from the client or
[[remoteClientList objectAtIndex:i] update:server];
from the server. I'll leave the details of setting up the connection and for getting the remoteServer or remoteClient reference to you after reading the Distributed Objects programming guide.
The downside of using DO is that you are tied to Cocoa; it will be very difficult to write a non-Cocoa client or server that communicates using Distirbuted Objects. If there's a chance you may want to have non-Cocoa client or server implementations, you should not use DO. In this case, I would recommend something simple with a lot of cross-platform and language support. A REST-style API over HTTP is a good option. Have a look at the Cocoa URL Loading System documentation for info on how to implement HTTP requests and responses. Have a look at Apple's CocoaHTTPServer example code or a code.google.com project of the same name for info on implementing an HTTP server in your Cocoa code.
As a very last option, you can take a look at the Cocoa Stream Programming Guide if you want to implement your own network protocol. NSStream's subclasses will let you listen on a network socket and handle asynchronous reads/writes to/from that socket. A lot of people use AsyncSocket for this purpose. It wraps the (lower-level) CFStream and CFSocket and makes writing network code somewhat easier.
When the server sends updates to the clients, it would probably be easier to just have one thread handle them all, and just use async sockets. Of course this would depend on how many clients you had to deal with too.
There's several networking examples in the apple developer side.
One I would recommend that you check out is the URLCache, which can be downloaded.
Quoting from the Apple's documentation for this example:
URLCache is a sample iPhone application that demonstrates how to download a resource off the web, store it in the application's data directory, and use the local copy of the resource. URLCache also demonstrates how to implement a couple of caching policies:
An interesting option is the BLIP protocol from Jens Alfke. It's like a stripped down version of BEEP: a message oriented networking system. It basically provides the low-level abstractions for a bidirectional message pipe so you can concentrate on layering your communication protocol on top of it.
It has some worthy followers such as Marcus Zarra (author of the CoreData bible) and Gus Mueller of Flying Meat software.
I don't know how you plan to design you system, but usually a server cannot connect to a client; the client must initiate the communication. With a low limit of 50 clients, you may not be looking at a web-server/client-like implementation...
That said, there are basically two ways to handle client server communication:
1. The client polls the server periodically to get updates
2. The client keeps a connection open to the server and the the server responds with a well known (as in both sides understand it) protocol.