I recently received the Microchip/Roving Networks RN42-APL development kit from Avnet, and I am able to get the sample iOS app to run and do loopback tests and everything is great (BT connects, authenticates, aware that app is on).
However, when I place this board in a real circuit, where data is flowing to the RX-In pins, the RN42 won't even authenticate!
Has anyone seen a functional example of this MFI chip? The whole 'it just works' isn't really ringing true. Is there something I need to -do- before this chip can send and receive data?
what exactly do you mean that the RN-42-APL BT module doesn't authenticate? I used RN-42-APL + MFi 2.0c chip for iOS authentication and it works well. However the newest firmware 5.43 has still some bug related to authentication with Android system. Previously I used BT module with firmware 5.36. Engineer from Microchip told me, that previous firmware had some bugs related to authentication which requires PIN code.
The newest firmware has been improved, but I found another one bug during my tests.
MFi chip must be connected with 2-wires to BT module. This chip uses I2C data transfer. I designed and constructed real device which was based on these components.
Finally, this module works well with iOS, authentication mode you can change with SA,x command. Please read the manual. There are 4 options: 0, 1, 2 and 4.
So I figured out the issue (I think). It was unrelated to the firmware, but it seems that the device wouldn't authenticate if there was traffic on the UART lines before authentication had happened.
I don't know whether where this limitation comes from, nor do I really care, but if anyone runs into this, I would try shutting off UART traffic until authentication.
Related
I'm writing some code (C++) for ESP32, to act as a BLE beacon. The problem is this: the iPhone doesn't send out its real MAC address, but does a random-generated MAC address, for security. The thing I'm confused about is how do you know if it's a device you've previously paired with?
So let's say I detect a new BLE MAC address, and looking at the manufacturer data I can determine it's an Apple device (first 2 bytes are "4C").
Now I need to know if I've previously paired with that device, so that I can allow the ESP32 to initiate an action (for simplicity let's just say turn on an LED). If that MAC address is in a list of known devices, then I can continue, and if not, I ignore it.
The problem is, if the iPhone is not giving up the real MAC address, the detected MAC address will never match anything. As this is a security situation I'm sure the algorithm for generating those MAC addresses is not known.
To be clear: this code is being written for the ESP32, not the iPhone.
It is in fact not possible to tell if a device has been previously seen, unless you pair and establish a bond with it. Once you pair with the device, long-term keys are exchanged and are used to quickly re-establish the connection.
This is by design. MAC addresses were originally unique, but this allowed tracking people and devices without their consent. You can read more about this in the following ESP-IDF guides:
GATT security server walkthrough
GATT security client walkthrough
So are you using esp32 as a beacon? This dose not involve any pairing or iOS MAC addresses. iOS will just be able to listen and the esp32 will not even know someone is "listening" to its broadcast.
Probably iOS application can store which services it is interested to hear to; may looks like pairing.. but it is a high level application managed technique and not any related to what BT standard calls pairing.
We are developing a mobile application that tracks users while they are picking up and delivering commodities. We have overcome many issues, including poor connectivity in rural areas, the app going into the background, and so on.
One issue continues to befuddle us. When receiving calls some drivers lose connectivity, other drivers will gain connectivity, and others (most) have no change in connectivity.
I remember earlier that Verizon iPhone users couldn't access data while on a call. Naively I thought that this issue was completely overcome, but perhaps it is not.
My understanding is that a) there are still some cellular protocols that cannot handle voice and data and b) there are (or were) some settings in mobile phones that give the user a choice.
I have searched for some list of cellular protocols and iOS and Android settings but so far come up empty.
Any guidance would be greatly appreciated.
Hopefully this will provide some more clarity; it all depends on the Radio Access Network (RAN) technology they're using (2G/3G/4G) and the terminal itself's capabilities.
There's 3 umbrella terms of technologies, each with their own revisions and variants, but this should cover it:
LTE (4G) only supports voice calls via VoLTE (Voice over LTE). Calls made over VoLTE will allow the user to continue accessing data at the same time. Many devices & some networks don't yet have VoLTE capability, so they use Circuit Switched Fall Back (CSFB) to drop to a 2G/3G Radio Access Network for making voice calls. (If your terminal does this you then have that RAN's ability to allow simultaneous voice/data.)
3G - There's a few flavors of "3G", depending on the terminal and the RAN variant (UMTS / EDGE / CDMA / HSDPA / HSDPA+) you may be able to access data and be on a call at the same time.
GSM (2G) does not have this functionality, the handset is either in Circuit Switched (Voice) or Packet Switched (Data) mode but not both.
The decision of which RAN to use is based off the priorities stored in the SIM/USIM, the received signal strength of the available networks and the capabilities of the terminal.
This means for example your users who may gain connectivity may find themselves using a 3G access technology on a 4G enabled terminal, with VoLTE support, jumping up to VoLTE to make the call. (Some operators resell to MVNOs but default to slower / older RAN technology like the 3G family)
Others may loose connectivity as you've seen, if they're happily using LTE on a device with no VoLTE support and need to drop to 2G/3G for a call (CSFB) they may loose data services as they're back to the limitations of these older RAN technologies.
I am just bit curious. I am new in IoT and currently started working on it using ESP8266 device. I know that it needs some firmware to write and install, like smart.js.
But I have read, Jasper (http://www.jasper.com/) can connect any device and manager, monitor etc. So I am bit curious how it works internally. I am not sure whether it installs firmware created by Jasper or in other way. I was reading this article: http://www2.cumulocity.com/guides/users-guide/jasper/#link-sims
Anyone knows about this? I mean how Jasper works to connect to any devices?
Cisco bought Jasper, which is useful for IoT business. However it might be better way for you to check Interactor(www.interactor.com) which is great for IoT development. Interactor works to conntect to any device with any protocol.
Cisco Jasper should not be confused with device management libraries (whether they be server based, or device based or both).
Jasper is a telecom based service that allows you to see and manage the connection state of sim inserted in the device. Regardless of the state of a device, the modem and sim (provided they are powered) will connect to the telco and provide basic information about the connection.
Think of it as a network tool (server originated) for the gateway on the device, not the device itself. It allows you to force disconnect devices from the network, ban sims from the account so a stolen or runaway sim can eat through data, basic connectivity tests (is the modem powered, does the sim have permission to transmit data over the network, etc).
The main value of jasper is that it allows you to manage you data costs by applying the appropriate rate plan to each device, and disconnect devices that are using too much (for whatever reason).
Jasper does not cost anything to use, however telcos will apply a rev commit (min monthly spend) usually $500/month to gain access. the sims are the same as PCS (phone) sims, but they are on their own network internally, and are specific to that telcos jasper. i.e. you can't take 500 devices using PCS sims, and import those sims into jasper. you'd need to do a physical swap of the sims.
I have just delivered a prototype for a big client, everything was fine but I'm now curious to know if the solution/architecture I've chosen was the right one or there's place for improvement in case the project will keep on.
The task was to build two iOS apps: one running on 5 different iPhones, and another running on 2 iPads. Basically the iPhone applications had to communicate information to the iPads, and occasionally they also had to send information between each other (iPhone to iPhone). All the infos where small JSON objects/chunks whose size was small, really small.
The app was not intended to reach the app store, is a working prototype to test out some ideas in a user testing environment.
I discarded bluetooth because we are talking about a peer-to-peer communication, not a one-to-one.
What I did was to use web sockets thanks to SocketIO, through a small Node.js server that was running on my mac. The server was really simple, just receiving the messages from the clients and broadcasting information to the other ones.
What do you think? Is the solution I've chosen ok, or there are better ones?
For example, this morning I've just found out these thread here on SO, and I've discovered I could have used GameKit. What do you think?
Socket.IO is nice because it is fairly simple to implement but it has the downside of requiring a central server. If you wanted to avoid that, you could use the Multipeer Connectivity framework that was introduced in iOS 7.
It will let you create one-to-one communication channels between devices on either the same WiFi network or Bluetooth. Once the channel is created, you can send whole NSData objects (or create streams but it doesn't seem relevant to your use case).
A good read : http://nshipster.com/multipeer-connectivity/
The WiTap sample from Apple demonstrates peer-to-peer networking over Wi-Fi and Bluetooth. Using Bonjour, the application both advertises itself on the local network and displays a list of other instances on the network. Supports infrastructure networks, peer-to-peer Bluetooth, and peer-to-peer Wi-Fi (on compatible hardware).
I have personally tested it and it works fine and well documented.
I think socket.io is the best choice. It is built on top of engine.io (which in turn is built on the fastest websocket implementation: ws) It has oldest to newest fallbacks, so it starts with long polling and works its way up. This guarantees a quick initial connection instead of needing to poll the device for features. You can read more on this here. Best of all, it handles everything seamlessly. You write your code as if websockets are supported on connecting devices and if not it will use other methods behind the scenes.
This post details many of the websocket libraries you could use with your server. Which websocket library to use with Node.js?
I am convinced Bonjour is the best solution:
Apps can also leverage Bonjour to automatically detect other instances
of the app (or other services) on the network.
However I've never used it myself; perhaps someone who has can comment?
I'm trying to find out what AWDL is. On iOS, if you use Apple's peer-to-peer networking over BlueTooth, it seems Apple creates a new Network Interface "awdl0" to implement (I guess) IP-over-BT.
But I can't find any docs on this tech, or this interface, how it behaves, things we must / must not do with it, etc. Google comes up blank :(.
In particular, I believe it means "established a BT connection, and I'm running an IP bridge over the top, and you can use this to communicate peer-to-peer". Apple's own system libraries have bugs where this bridge isn't setup quickly enough, and if you send data too soon, it appears to get dropped by the OS. So ... if I can query this awdl0, I hope to check "are you ready yet?" and delay P2P messages until the OS is happy.
UPDATE
More info: I can get pairs of iOS devices to create awdl0 connections to each other - but they never get created to OS X machines, whether BT and Bonjour are on or not, whether the devices are paired or not.
Some background:
In iOS5, Apple permanently disabled the Bluetooth parts of Bonjour/Peer-to-peer networking, and published a technote instructing everyone to use DNS-SD if they wanted to keep using Bluetooth as a transport between iOS devices. This is fine, but it means you must use DNS-SD if you want high-performance BT, and you want it reliable.
(GameKit sometimes works fine, but we often see terrible performance in real-world scenarios, e.g. crowded public places - which goes away if you use DNS-SD)
DNS-SD protocol doesn't include info to tell you what the hardware is using. But it does tell you the Network Interfaces (which is how I know we're running on awdl0)
DNS-SD is awesome, and we have high-speed, low latency connections peer-to-peer between iOS devices - all the stuff that GameKit promises but often fails to deliver whenever there's more than a few wifi/BT devices in range.
AWDL recently caught a lot of attention when it caused Wi-Fi issues in iOS 8 and OS X Yosemite devices.
What is AWDL?
AWDL (Apple Wireless Direct Link) is a low latency/high speed WiFi peer-to peer-connection Apple uses for everywhere you’d expect: AirDrop, GameKit (which also uses Bluetooth), AirPlay, and perhaps elsewhere. It works using its own dedicated network interface, typically “awdl0".
While some services, like Instant HotSpot, Bluetooth Tethering (of course), and GameKit advertise their services over Bluetooth SDP, Apple decided to advertise AirDrop over WiFi and inadvertently destroyed WiFi performance for millions of Yosemite and iOS 8 users.
How does AWDL work?
Since the iPhone 4, the iOS kernels have had multiple WiFi interfaces to 1 WiFi Broadcom hardware chip.
en0 — primary WiFi interface
ap1 — access point interface used for WiFi tethering
awdl0 — Apple Wireless Direct Link interface (since iOS 7?)
By having multiple interfaces, Apple is able to have your standard WiFi connection on en0, while still broadcasting, browsing, and resolving peer to peer connections on awdl0 (just not well).
You can find more info here and here.
I'd like to provide a more precise answer as to how the protocol works internally. I quote part of the abstract of this paper.
In short, each AWDL node announces a sequence of Availability Windows
(AWs) indicating its readiness to communicate with other AWDL nodes.
An elected master node synchronizes these sequences. Outside the AWs,
nodes can tune their Wi-Fi radio to a different channel to communicate
with an access point, or could turn it off to save energy.
From a user perspective, AWDL allows a device remain connected to an infrastructure-based Wi-Fi network and communicate with AWDL peers "at the same time" by quickly hopping between the channels of the two networks (AWDL uses fixed social channels 6, 44, and 149). In contrast to the previous answer, we found that current versions of AWDL work fairly well and channel hopping only induces a small overhead.
Disclaimer: I'm co-author of this paper and we retrieved this information by means of reverse engineering. If you are interested in the details, please read the paper and have a look at the Wireshark dissector (published soon).