I have a requirement to have a cross-platform program --- intended for mobile devices such as Android, Brew, Bada, WinCE etc --- be able to communicate with other instances of itself via Bluetooth.
Unfortunately:
the Bluetooth APIs on such devices are all radically, radically different.
the terminology they use is also radically different.
what actually works is frequently radically different to what they say works.
So far I've discovered that Android will allow you to connect to or listen on RFCOMM services specified by a simple UUID, but does not allow more complicated manipulation of SDP records; Brew claims to support SPP but the API appears to allow arbitrary RFCOMM; Bada supports SPP but doesn't allow you to specify the UUID, so I have no idea how you're supposed to do service discovery or listen for two things at once...
Oh, and iOS doesn't allow Bluetooth communication at all to non-iOS devices.
So:
I can't be the first person to need to do this. Is there a known subset of Bluetooth functionality that I should be using in order to maximise portability?
Device makers usually implement some bluetooth profiles such as A2DP, OBEX, etc. Depending what you want to do, you should check that all your target devices implement the required profiles.
Note that even though a device can implement an specific profile, there may not be an API that will allow you to use it.
See http://en.wikipedia.org/wiki/Bluetooth_profile.
Related
I'm doing an embedded-system project now. From my view, AT commands can be sent to a device to retrieve 4G information, dial and so on. On the other hand, we can also do that by calling APIs provided by the 4G vendor.
My question is what's the relationship between them? Is the API a wrapper for the AT commands?
TL;DR
Vendor's API (not only C, but also C++, Java or Python depending to the vendor and the modem model) can both be wrappers for AT commands and a wider, more powerful set of API were the user can port complex applications.
It depends on the vendor and on the model.
A jungle of modems produced by different vendors
It is impossible to define a general "rule" about API provided by a Cellular Module (not necessarily a 4G module).
First of all every vendor usually implements standard AT Commands (both Hayes commands and extended standard commands for cellular devices). In the same way every vendor has it's own implementation of the user application area where the customers can store their own application to control the modem's functionalities and to use them according to their own application requirements.
AT commands remain the interface to be used when the modem needs to be connected (and driven) by an external host. When the user application area is used, instead, a wider set of API is usually provided. They may include:
A library exporting a subset of the OS capabilities (threads management, events, semaphores, mutexes, SW timers, FS access and so on)
A library offering the capability to manage the specific HW of the device (GPIOs, SPI, I2C, ADC, DAC and so on)
A library offering a programmatical way to perform action, related to connectivity, that would normally be executed through AT commands (registration status check, PIN code insertion, PDP context activation, SMS management, TCP/UDP/TLS sockets)
The latter usually access a base layer involving all the functionalities provided by the modem. Usually this is the same layer invoked by the AT commands sent through modem's serial interface.
Sending AT commands... from the vendor's API?
Of course it often happens that the library mentioned above provides just a subset of the functionalities usually exported with the AT commands set so, in order to "fill the gap", a further set of APIs is usually exported as well:
A set of functions that allow the simulation of AT commands sent to the modem's serial port. Sending them and parsering the responses they send in the vitual internal serial/USB interface allow the user to port in the internal user application area the the application they previously run on an external host processor (with obvious BOM benefits).
As an example, please check Telit Appzone here and here. It was the inspiration of my answer because I know it very well.
I don't know why you name the title that there's a relationship between AT command and Linux-C API.
Regarding AT command, you can take a look at this wiki article for general information.
Each module has a specified AT command sets. Normally, the module manufacture just offers AT command set and what return values are.
Is API a wrapper of AT command?
If you can use the API provided by the manufacturer, then yes, it's a wrapper of the AT command handler.
My question is what's the relationship between them? Is the API a wrapper for the AT commands?
It is impossible to be sure without having any details of the device, but probably any C API for it wraps the AT command set, either by communicating with the device directly over an internal serial interface or by going through a device driver that uses AT commands to communicate with it.
However, it is at least conceivable, albeit unlikely, that the 4G device offers an alternative control path that the C API uses (definitely via a driver in this case).
I'm not quite sure what the point of the question is, though. If you are programming the device and its 4G component in C, and the manufacturer has provided a C API, then use it! If you are programming in some other language then at least consider using the C API, which you should be able to access from most other languages in some language-specific way. You should not expend effort on rolling your own without a compelling reason to reject the API already provided to you.
I am finding some conflicting articles, some are old, about CN1 not having Sockets but I see the library com.codename1.io.Socket. I have seen some articles saying it works on Android as well but not iOS. I need the capability to listen on a socket on iOS and was hoping to use an internal library. The shannah/CN1Sockets project doesn't appear to support listening.
From 2014, https://www.codenameone.com/blog/sockets-multiline-trees.html , and lists non iOS support. Any update on this?
Codova/Phonegap does have a few libraries and someone implements Chrome's TCP/UDP API for it as well.
Server sockets are very problematic across platforms as the iOS implementation is radically different from the Android implementation and a bit challenging to implement using the listen paradigm.
It's probably possible to implement server sockets on iOS but because there wasn't much demand and this required some work we chose not to do it. It's also not very useful ans phones move around/change networks. You won't get a stable IP to work against anyway. A better way would be to initiate communication from the client and then communicate back. Notice you won't be able to use a server socket in a background process in iOS anyway as the process will be killed when sent to background!
The only Cordova implementation I found is this: https://github.com/MobileChromeApps/cordova-plugin-chrome-apps-sockets-tcpServer
You can probably use that with native interfaces or just use it as a baseline for a pull request to implement server sockets on iOS but again it's very unlikely that what you are trying to do with server sockets won't work due to iOS limitations.
I would like to use an arduino with a bluetooth module to modify the volume and skip songs on my phone.
All the information I found was about how to code an application that would communicate with a device via bluetooth, which isn't what I am looking for. I want to know what protocol I should follow to connect to an android device via bluetooth like a car radio would do.
My goal is to be able to use my device as a remote to control the built-in music application.
I think you are looking for the AVRCP protocol. Please send more info about your hardware so I can digg a better answer (if you need more, anyways...).
I am planning to build a micro controller (a switch will be attached to the embedded system which contains this micro controller) and this embedded system will be connected through a wire to mobile phone. My objective is to dial a particular number through the connected mobile phone network when the user presses the switch on the embedded system. ( planning to use AT commands for dialing). After extensive search, I have found that it is possible to do this above task. Some of the questions I have on this :
a) Do we have to install any drivers on the micro controller to communicate with mobile phone (for sending AT commands) i.e., is it sufficient if we simply code the related AT commands in the micro-controller (in C++) ?
b) Many people were using F-bus protocol for this above objective. Is there any other general protocol similar to this which can help for communicating with all mobiles (samsung,nokia,sony..)
I have read extensively in SO also. But, I have not found any question regarding the drivers. I would appreciate any kind of help
Thanks
A driver is nothing more than a software that allows your system to interact other devices, and is usually associated with Operating Systems (the driver might provide an abstraction layer for your communication). Do you plan to use an Operating System at all?
In any case, it is quite obvious that if you want to communicate to another device you need the software to do so. The question is if you write it your self or if you get an "off the shelf" solution.
In many cases, particularly when a device uses a proprietary communication protocol, you have no option but to get a driver to communicate with it, and that most likely will require you to have an Operating System.
If cellular communication is all you need, there are MUCH easier solutions available (particularly if you intend of turning your project into a product). Search for "embedded modems" or M2M solutions. There are lots of available modems to which you connect using RS232, and can send the AT commands directly. Telit and Multitech are two providers I've worked with and are really easy to interface with.
I have a dsPIC33 with ECAN and wish to establish a protocol (using SDO if possible) in such way that it communicate between terminal software and dsPIC33 where I can perform diagnostics within dsPIC33 and supporting ICs.
I do not know what is required, so what is a low cost way of doing this? I could use a CAN-to-USB device, but I am unsure if this will work. What kind of protocol inside CANUSB wraps around the ASCII-based message?
What hardware can I use? Can it be used to monitor the CAN bus as well? I do not wish to invest in an expensive setup as in Vector or similar heavy-weight solution.
When you purchase CAN interface hardware, it does not typically include software to work with specific upper-level CAN protocols (like CANopen). They do usually come with a set of DLL files that allow you to write custom PC applications to interface with your hardware.
If you do not want to purchase any third-party software, then you must:
Implement a basic CAN driver for the dsPIC33 (transmit and receive a basic frame).
Implement the CANopen SDO protocol on top of your basic driver on the dsPIC33.
Purchase a low-cost CAN<->USB interface (which should come with DLLs that allow you to develop in C, C++ or C#.
Write a PC application using the DLL files which implements the CANopen SDO protocol.
You may want to look for open-source implementations of the protocol. One such implementation is CanFestival. However, I have never used this library.
You can download an open source project for CANopen from DATALINK ENGINEERING as this seems to be just what you need.