Hope this is the right place to ask - assuming so as it is related to programming.
I am looking for some hardware (say a dongle) that would open up an API for my computer to a SIM card. Does that exist anywhere?
The idea would be that I can then use my existing SIM card on its existing network/contract and with a bit of code, send/receive calls and texts. I figured that if a phone can be programmed to do it why can't a computer? I just need the hardware.
Any suggestions if this kind of thing is possible? Even by maybe integrating a phone?
You can use AT commands with any modem or phone, whose driver exposes a modem port when you connect it to a computer. Plug in the phone or modem, and go to Windows Device Manager, and look under "Modems" and see what you've got. From "properties" of the Modem, you can see which COM port it is on.
AT commands are an older method of communicating with a modem. There is a standard set of commands for GSM/GPRS/3G/4G devices available from 3GPP.org, here. Manufacturers add their own proprietary commands for more obscure functions. Many but not all of these are in the public domain.
Some newer plug-in modems may appear as a network adapter (you can see this in Windows), due to their drivers. In this case, you can use the following interfaces:
on Vista: NDIS, proprietary interfaces
on Windows 7 and 8.x Desktop apps: Windows Mobile Broadband API
on Windows 8.x, in the Metro/app area: Windows.Networking and MobileBroadband APIs.
on Windows 10, UWP, there are UWP APIs here. But they do not give as much functionality as the Desktop APIs.
On Windows 8.1 and Windows 10, if the appropriate drives are present it is possible to use the new MBIM interface via the desktop Mobile Broadband DeviceServices API. Mobile Broadband Interface Model spec available here.
On Linux, use AT commands via the serial port.
I'm a bit puzzled by your requirement to make (voice?) calls via a phone connected to a computer. Do you mean Skype? In this case, of course, you wouldn't need any interface for making calls, you would just open an IP connection over a data session - which can be done via any of the above interfaces.
(added this comment as an answer, as there was more information)
I use this GSM device: http://www.mikroe.com/click/gsm2/ connected to a basic UART like: https://www.sparkfun.com/products/718?gclid=CIj1xOzbur4CFUVbfgodCpQASQ
Then use AT COMMANDS.
I also use a piece of software called QNavigator to inspect the modem/gsm: http://www.soselectronic.com/?str=1329
Related
I seem to only be able to access physical ports. I do want to access virtual ones like ones created with virtual null modem or virtual serial port driver.
Does anyone know if this is possible.
Chrome enumerates serial ports by calling SetupDiGetClassDevs with GUID_DEVINTERFACE_SERENUM_BUS_ENUMERATOR. As I discovered when implementing this enumeration logic there are a surprisingly large number of ways to ask Windows for a list of all available COM ports. The advantage of this approach being that it provides device information which can be used to get the human-readable name of the device and USB product identifiers if it is a USB device. It is likely that a virtual COM port driver may be creating the device in a way which prevents it from being discovered this way.
I've created https://bugs.chromium.org/p/chromium/issues/detail?id=1238369 to track this as a Chrome bug. Please comment on whether you are using a different virtual serial port driver than the one mentioned there.
I managed to get Chrome to see the virtual serial ports using com0com on Windows 10 21H1 (OS Build 19043.1110). Chrome connects to the port successfully and it works as expected:
We've got two WinCE devices that need to talk to each other, they don't have WiFi or Bluetooth so I think a wired USB connection is our best chance. I've been reading up on using ActiveSync and serial over USB, but all the articles are geared towards talking between a WinCE device to a full Windows box, never between two WinCE devices.
If we can get ActiveSync working, that's fine, the other option is just to open COM ports on both sides and write our own communications protocol.
Given the project timelines, writing any sort of device driver isn't an option, this needs to be something that is built in to WinCE.
We are building WinCE for both devices, so I can make any modifications necessary at that level.
Is there a way to get these two guys talking to each other?
If you can't write your own driver then your fastest route is probably to get a USB to serial converter for both devices and then connect them via serial.
Obviously, you'll need to choose one that has support for Windows Mobile. I think FTDI based adapters should work.
Once that's working you just use the built-in serial API to read and write data.
I purchased a BLED 112 dongle from BlueGiga (http://www.bluegiga.com/BLED112_Bluetooth_smart_dongle). I purchased the dongle since I was trying to do a simple POC with an iPhone. I did not want to get into breakout boards or the dev kit just yet.
I am trying to get the heart rate monitor samples working and I am not sure how to load the firmware on the device. I am using the latest version of the SDK (v1.1.1) which states to use the BLE Update tool, not the TI Flash Tool.
However it looks like you need the CC Debugger with the BLE Update Tool to update the SOC. I looked at the CC Debugger and it does not appear to be designed to be used with BLED 112 USB dongle. It appears you need a breakout board to expose the pins to be able to hook the CC Debugger to a BLE 112 module, not a BLED 112.
Lastly, I am not sure if DFU will work without bricking the dongle.
Any advice on how to properly use and program the BLED 112?
Thanks,
G
From the SDK docs:
TI Flash tool should NOT be used with the Bluegiga Bluetooth Smart SDK
v.1.1 or newer, but BLE Update tool should be used instead. The BLE112
and BLE113 and BLED112 devices contain a security key, which is needed
for the firmware to operate and if the device is programmed with TI
flash tool, this security key will be erased.
It is possible to update the firmware on the BLED112 via the USB connection, and without requiring a breakout box or a CC Debugger. However, it is fairly easy to accidentally 'brick' your device in so doing. The problem is that the firmware itself needs to provide the interface to enable DFU mode; if you do an update with your own firmware, and your firmware doesn't provide this capability, you're stuck with the last thing loaded on it.
That being said, here's the process.
The BLED112 dongle is essentially just a BLE112 with an attached USB connection. The BlueGiga SDK ships with drivers that allow the device to be mapped with a simple serial interface, such that the device shows up as a simple COM port (e.g., "COM16") to applications running on the host PC. The SDK also ships with two utilities - BLEGUI, and DFUTOOL - that are able to use this COM port interface to communicate with the device.
(Getting the drivers installed seems like it should be easy, but the process was finicky for me, and I ended up having to mess around with Device Manager, etc., for a while before getting the COM port to show up reliably when I attached the dongle.)
The basic process for building and installing firmware on the BLED112 is:
Compile your BGScript program to an image file using BGBUILD.EXE
Reboot the dongle into firmware update (DFU) mode using BLEGUI2.EXE
After attaching to the appropriate COM port, select Commands | DFU from the menu.
Update the firmware using DFUTOOL.EXE
Before you do this, make sure you read the "Developing Bluetooth 4.0 single-mode applications" and other technotes from BlueGiga's forum (registration required). Specifically around your project configuration:
WARNING:
If the firmware is to be installed into the BLED112 USB dongle the USB
CDC configuration MUST BE included in the project file. If this is not
included in the project file and the compiled firmware is installed
into the BLED112 USB dongle, the USB interface will be disabled and
the dongle stops from working.
Phew. Not necessarily for the feint of heart. I personally found it more appealing to shell out the money for the DKBLE112, which has the BLE112 module mounted on a board with some other accessories, and a CC Debugger for programming. With this setup, you can flash new images to the chip without worrying so much about screwing things up (there's a "reset" button on the board itself).
Other people have reported using breakout boards that are cheaper than the DKBLE112, such as this one from Jeff Rowberg. They also let you program with the CC Debugger, but I have no experience with them.
Have fun!
Based on the information provided, I found the following technote on the BlueGiga support knowledge base.
https://bluegiga.zendesk.com/entries/22810076--HOW-TO-Run-a-BGScript-application-on-the-BLED112-USB-dongle
Thanks
Greg
We are developing some device and we need to find good solution for one of needed functionality.
Thing is that we need communicate WinCE 6.0 (ARM) and Windows on PC.
Easiest way is of course COM port but in our case it is impossible (all serial ports are used on WinCE and we don't want to add one more).
Second option is LAN but for us it is not the best option for few reasons.
So there is third option we could use. USB to USB communication but how to do that ?
Of course WinCE is USB Device and PC is USB Host so all hardware basics are meet.
We could use Active sync but there are few problems with it:
- WinCE 6.0 is not working with WMDC (drivers on device just crash after connecting device with PC) and I didn't find any solution for it so in this case we need to use WinXP on PC side (old ActiveSync)
- we need to filter communication with active sync to only our application, no other non authorized software should be allowed (what I know this is imposible to obtain).
So propably best way to do what we need is to communicate throug USB like standard COM (serial communication).
The question is, how it could be made, are we need to write driver on WinCE and also a Driver on Windows (PC), or there are better solution? Maybe some driver for WinCE 6.0 that would emulate Virtual COM on PC side (and of course allow standard Read/Write to it on WinCE side) ? Could someone tell me if something like that exists ?
We probably found best solution for our problem. We use TCP/IP over ActiveSync (standard WinSock connection over USB). It is possible because ActiveSync provides an IP address for Host PC. It can be acquired trough something like that (on WinCE):
std::string lIPAddress = "ppp_peer";
struct hostent * lH = gethostbyname(lIPAddress.c_str());
DEBUGMSG(ZONE_ERROR, (TEXT("Addr: %S\r\n"), lH->h_addr_list[0])); // just a debug info
lServerAddress.sin_addr.S_un.S_addr = *(u_long *)lH->h_addr_list[0];
Of course this is not full example, it's just a sample :)
I want to implement bluetooth communication on my final bachelor project, but I'm having a lot of doubts.
One of the requisites of this project is to have a Java application that can talk to the micro via Bluetooth. After a lot of research, I've found one that I think it's very good with a SPP profile, but I still have a lot of questions about it:
All the bluetooth on a PC implements the SPP profile stack?
If you need to develop a Java application that runs on every PC that implements the SPP stack, how would you do it?
We started by trying to use BlueCove and JavaBluetooth.org API, the first one runs great but I don't know if it's just on my PC and the second one sends an error (Stack not initialized). Which one would you use, and why?
We decided to buy this bluetooth module, from Sparkfun, any comments for those of you who already use it?
Thanks
I used a similar product for my senior design project from Sparkfun (RN-41): http://www.sparkfun.com/products/10559
It worked right out of the box as a simple UART. This allowed my team and I to develop a simple C# application that used the .NET SerialPort class (System.IO.Ports) to communicate between an MSP430 and the PC application we were developing. If streaming data is all you care about, these Bluetooth modules work great. Java implements a similar SerialPort class for RS-232 communications. Don't forget that Bluetooth was developed to replace a serial cable.
I hope this answer helps! Good luck.
I personnally achieved to use the Sparkfun's bluesmirf devices to communicate with my own Java application (an Eclipse plug-in). I tested it successfully under Windows, MacOS & Linux based systems.
I used the RXTX Java library to connect to the corresponding serial port once the Bluetooth devices were paired. Under Linux I even achieved to configure rfcomm to automatically pair the Bluetooth devices on demand.
From my experiment I encountered some stability issues... Sometimes it simply fails to connect to the given port even if it exists or refuse to reconnect on it. Sometimes it hangs the whole system...
I never found any good solution to fix those issues that seems to be completely system dependent. I would be interested if any one achieved to use it properly...