So, I have this scanner device that scans barcodes. I want it to connect through the USB. I'm not sure how to get the data from the device once it gets scanned. I know it records the barcode info in hexadecimal, so when the data arrives to the application, some conversion will have to take place. But, I'm still very confused on how to actually digitally connect and communicate with the device.
I saw online to try and use IOKit.framework, but I believe it's for MAC, which I'm not using. I'm trying to do it through iOS in the iPhone simulator.
I also have a command list of hexadecimal commands I can send to the device, However, I don't know how to actually send the message to the device.
Apologies if I was a little repetitive. Thanks in advance!
You can't.
iOS Simulator has no access whatsoever to any USB device connected to the Mac.
Related
Background
I'm using a couple of different hobbyist BLE devices (HM-10). This particular one is an example of one of them.
It's a simple 4-pin device and I've set all the parameters on it using an Arduino Nano and I can see the data coming into it live since it is connected to USB of my computer and I'm monitoring serial data using Arduino Serial Monitor.
The device works great. I have it set to Type 3 which forces it to pair/bond (so iphone or ipad will force you to enter the 6-digit PASS code, which I've set on the device.
iPhone App Works
I have written a simple Single-View iOS app which runs on my iphone / ipad and finds local BLE peripherals.
Everything works great.
When I select the item (HM-10) shown above by name I see the iOS pairing dialog & successfully pair the item.
I can send data and everything works fine. If I go out of distance or turn off bluetooth on my device then come back into proximity or turn the device back on, then the iphone can send data again and I see it in the Serial Monitor. Works great.
** The Problem **
The problem occurs if I then pair this device with any other iphone or ipad.
After that, the new iphone / ipad can send data to the device with no problem.
However, if I then go back to my original iphone and attempt to send data again, I see the following error raised by the CBCentralManager:
"Peer removed pairing information."
After that, I cannot send data from the original iphone to the device again, unless I go to Bluetooth settings on the phone and say, "Forget this device".
Android & HC-06 Bluetooth Devices
I've developed simple Android apps which use a similar Bluetooth classic device (HC-06) and I could pair multiple devices.
Questions
Does BLE 4.0 Allow multiple devices to be paired & bonded?
Do you know why the Peripheral would remove the pairing info? (again, this only occurs if I pair the device with a new iphone / ipad).
Is there a way to send something via iOS app that would tell it to renew the pairing information?
Do you have any suggestions (code to try or other) that would allow me to definitively know that this device does or does not allow multiple phones to pair with it? (I've contacted the manufacturer also.)
Note: I also have a another BLE device here and it seems to exhibit the same behavior. This seems odd though, because I have a BLE speaker that will pair with multiple devices so it must be possible. And I understand that could depend upon the BLE hardware.
Does BLE 4.0 Allow multiple devices to be paired & bonded?
Sure. But that doesn't mean that the device does. It needs to allocate memory for it, and smaller devices often don't.
Do you know why the Peripheral would remove the pairing info? (again, this only occurs if I pair the device with a new iphone / ipad).
It doesn't remove the pairing info. It's telling you the device has removed the pairing info. Pairing info includes a shared secret, so if one side throws away their secret, there's no point in you keeping yours. You have to create a new one.
Is there a way to send something via iOS app that would tell it to renew the pairing information?
Unfortunately no. Apple doesn't give any access to the pairing experience.
There isn't any standardized way to ask devices this kind of information. Some devices support a single pairing Some support two. Some support "a few." But it's really up to the device.
It is very possible that you will get a better overall experience with a Bluetooth 4.1 or 4.2 device, because they've added better security protocols. With iOS 13, the phone also supports cross-transport key derivation, which possibly will help here (if the device also supports it). But I don't think you can improve things with a Bluetooth 4.0 device.
I'm developing a macOS app which needs to detect & get information from connected iOS devices via an USB cable.
I've read here how I can get the name of the devices connected via USB, but I'm only able to get a short name of the device (i.e. iPhone instead of John's iPhone)
I'm looking for a way to retrieve the device's full name, and other information about the device: iOS version, device id, carrier etc.
Can this be achieved using Swift?
Thanks to #Robert's comment, I found out about libimobiledevice's ideviceinfo which does what I needed. I couldn't find a way to directly include it in my app, but I found the imobiledevice-net repo, which has macOS libraries on the release page.
These libraries can be used with the help of Swift's Process class.
I would like to use a Apple mobile device (iPhone, iPod touch) to connect to a Windows CE device via bluetooth, but it failed. Iphone returns an error message that the device is not supported.
I understand about the MFI process but it's too difficult to get approval from the Apple MFi Team for a Windows CE device so I don't even bother to try.
Another way is change the bluetooth profile in the WinCE so make it as a headset or bluetooth keyboard so hopefully Apple can discover it as another device and accept the connection. I have the CERegEditor to modify the registry and also a COD generator from this link (http://bluetooth-pentest.narod.ru/software/bluetooth_class_of_device-service_generator.html). I modify the bluetooth profile successfully on the device and verified by Android. However, I'm still not able to use a iPhone to connect to it.
I tried to make it as a wireless headset or hands-free but it's not discoverable by the iPhone, or it just directly refused to connect.
If I made it as a keyboard, it's discoverable by the iPhone, but it doesn't connect after I send a pair request and type in the correct 4-digit pin. iPhone returns the "out of range" error even it's just next to it.
I hope I can get some help here. I appreciate if anyone can share similar experience before or provide me an appropriate COD code which works for you, or any other methods that can let me to make a connection.
Thanks for your attention.
I would like to use an iOS device as a camera and stream the data to an accompanying OSX app. Wifi is not a valid option and I'm assuming Bluetooth will be too slow, so I'm planning to connect the phone via USB to the Mac.
I've gone through this networking tutorial and have looked at Apple's EADemo code with EASessionManager, etc. but haven't figured out how to put everything together.
When my iOS device is connected via USB to my Mac, it doesn't show up in
[[EAAccessoryManager sharedAccessoryManager] connectedAccessories]
so I'm kind of lost. Am I going down the wrong path? Any suggestions would be really helpful! Thanks in advance!
I downloaded the iOS SDK for the Linea Pro device from their website and have successfully implemented some of it in my App - but I noticed the device never seems to work while its connected to the Mac via the USB cable. I've verified this 100% because as soon as I disconnect the LineaPro sled from the USB cable and run their Apps, it finds the Scanner and works. Otherwise, nothing.
This of course makes debugging near impossible because if you're not connected to Xcode you obviously can't see any output the App may have in Xcode's Console. You can't NSLog anything to the console, you can't put Breakpoints, you can't step-through your code - you pretty much can't do any of the things you'd normally do when developing an App.
I've actually had to resort to creating UITextViews and outputting everything I can to them during runtime ( which of course clutters up the interface big time) but even with that, if the App crashes, you never get to see your TextViews: you're thrown out and back to the iOS home screen, staring at all your little icons.
I've got some other ideas regarding work-arounds - but that's just it: they're all work-arounds. Does anyone out there know if there's any way to use the Linea Pro while its still connected to Xcode?
I don't think this is possible. For some reason lightning devices and USB don't seem to work together well.
I would suggest a combination of https://github.com/fpillet/NSLogger for logging and https://github.com/Shopify/superdb for sending messages to your app. You won't get breakpoints but you will have a few more tools at your disposal.
If you are using a device running iOS11 and you are using XCode 9, you no longer need to connect via lightning cable to debug your runtime build. XCode 9 introduced wireless debugging via a network connection:
Wireless Device Pairing Apple Documentation
Facing the same problem. I've resorted to using UIAlertViews instead of UITextFields to log messages on screen, but still its a huge pain the the buttocks.
You can also fire up a local server and hit it via localhost:8001?logmessage=myLogMessageWhichCanBeVeryVeryLong
and just print these GET requests to the terminal. Not pretty at all but its a workaround that could be of use if you want to get real creative...
Usually if you have a bug or error in your code it's going to be YOUR code, not the actual scanner or scanner input. So what I do while the app is in testing mode, is to have a button or other UIcontrol wired up to run an action AS IF there was scanner input, and I'll provide a mock string of input in a string (different inputs by incrementing a counter if needed). That way I can test away in the debugger for as long as necessary. Once my code works for me & I'm satisfied, I paste the same code into the scanner function and make the switch to the actual scanner. A little pain but not a big deal.