[0:00] This talk was originally planned for iOSDevUK, but due to personal circumstances, I wasn’t
[0:05] able to give it.
[0:06] So I thought I’d put it up on YouTube for everyone to see.
[0:09] I’m sure we’ve all had that conversation - “Hey, you’re an app developer.
[0:12] I’ve got a great idea for an app….”
[0:15] Well, there’s a similar one to be had with people making hardware - “I’ve got an
[0:18] idea for a thing - I just need an app to go with it…”,
[0:21] We’re in a world now where everything is being made “smart”, it might be your lights,
[0:25] your washing machine, your fridge, or even your toaster.
[0:29] At some point, you are going to be asked to build an app that talks to hardware and you’re
[0:33] going to be asked what the best way to connect them together is.
[0:36] As always this video is sponsored by PCBWay - more about them later on.
[0:41] So, what are our options?
[0:43] We’ve got the old school plugging things together with a cable.
[0:47] Or, we can join Generation Z and cut the cable.
[0:50] We can go wireless.
[0:51] Now, I’m not going to talk too much about the cable option - if you need to head down
[0:55] that route then you’ll be signing up for the Apple MFi program.
[0:59] Your hardware will need to be tested by Apple to make sure it works and you’ll need to include
[1:03] a special chip so that the phone recognises your hardware.
[1:06] If you don’t then your get this nice pop-up.
[1:08] “Accessory may not be supported”
[1:11] The apple help for this alert is particularly unhelpful:
[1:14] Your accessory is defective, damaged or not Apple-certified.
[1:16] The accessory isn’t supported by your device.
[1:19] Your iOS device has a dirty or damaged connector.
[1:23] As I say, you can solve this by joining the MFi program, but I’m going to assume that
[1:27] for the majority of us this is all a bit too much.
[1:30] So this is out of scope for this talk.
[1:33] Most accessories that use cables nowadays are just chargers - and even that is going
[1:37] wireless now…
[1:38] So, what are our wireless options:
[1:41] We’ve got two options - Bluetooth or WiFi.
[1:44] We’ll cover Bluetooth first.
[1:45] The first thing we need to know is that there are two versions of Bluetooth - Bluetooth
[1:50] Classic and Bluetooth Low Energy usually shortened to BLE.
[1:55] We’ll be talking about BLE.
[1:57] BLE has an interesting history - back in 2001 Nokia started developing a low-energy wireless
[2:04] technology based on Bluetooth that they eventually published in 2004 with the name Bluetooth
[2:09] Low-End Extension.
[2:11] They were then joined by Logitech and ST Microelectronics and with the support of the European MIMOSA
[2:17] project, it was publicly released as Wibree in 2006.
[2:21] Finally, in 2010 it was made part of the Bluetooth spec.
[2:25] The first phone to implement this spec was the iPhone4S in 2011.
[2:29] It’s always amazing to me how much work and time goes into getting this kind of technology
[2:34] from research to a production device.
[2:37] Bluetooth Low Energy is an amazing technology - it really is low energy.
[2:42] Depending on your use case you could be looking at a couple of hundred microamps power consumption
[2:46] on average.
[2:47] To put that into perspective your iPhone has a battery that is between 2-3000mAh - if we
[2:53] were consuming on average 200 microamps we would be able to run for 10,000 hours - that’s
[2:59] more than a year.
[3:00] A lot of use cases you’ll see are designed around coin cell batteries - in these cases,
[3:05] they are generally asleep for the majority of the time, only occasionally waking up to
[3:09] advertise their presence and see if anyone wants to connect.
[3:12] There are a lot of really nice modules that support Bluetooth Low Energy - they’ll often
[3:16] also support additional protocols such as Zigbee - which can be really useful for talking
[3:17] to other devices.
[3:18] Just doing a quick search on RSOnline brings up around 250 results for Bluetooth modules
[3:21] - so there is a lot to choose from.
[3:23] These low-power modules tend to come packaged with an integrated ARM processor, along with
[3:28] a reasonable amount of flash and RAM.
[3:30] They also come with a lot of built-in peripherals so it’s possible to build your entire hardware
[3:35] around these modules.
[3:37] If you need a bit more processing power then you can easily couple these modules with more
[3:41] powerful CPUs and still get a low-power solution by sleeping the main processor when nothing
[3:46] is happening.
[3:48] Now the guys who produced the standards for BLE had a dream, a dream of compatibility
[3:52] and interoperability.
[3:54] They defined a set of profiles and services for different types of hardware.
[3:59] Manufacturers would produce hardware that conformed to these services and then people
[4:03] writing software could code against the profile and know that their software would work with
[4:08] any hardware.
[4:09] Each profile defines a set of services that can be offered up and each service defines
[4:13] a set of characteristics.
[4:14] For example, a Heart Rate monitor would implement the heart rate profile.
[4:18] It would provide the Heart Rate Service, with three characteristics, the actual heart rate,
[4:23] where the sensor is placed, and the heart rate control point.
[4:26] It would also provide the device information service with the manufacturer’s name as a
[4:31] characteristic.
[4:32] If you made a new piece of hardware then you could publish what services and characteristics
[4:36] your device used - you could even get it made part of the standard - and then other people
[4:39] could make the compatible hardware and software.
[4:42] They also wanted to create self-describing hardware - as part of your characteristics,
[4:47] you can provide descriptions that provide a human-readable name, what units to use and
[4:51] how to display the value.
[4:52] Here’s a list of all the predefined units.
[4:54] We’ve got some obvious ones such as - length in meters, mass in kilograms and time in seconds.
[5:00] We’ve even got units for the fans of Brexit and the fans of Star Trek.
[5:04] It does look like they tried to get pretty much every SI unit into the spec.
[5:09] The thinking was that people could produce quite generic software and have it work with
[5:13] pretty much any hardware.
[5:14] It would be a beautiful world of cooperation.
[5:16] But, what most people do is create their own custom profiles for their specific piece of
[5:21] hardware - and it’s probably what you will end up doing as well.
[5:24] So, if you ever get the chance to help specify some hardware, please encourage them to add
[5:28] human descriptions and units.
[5:30] So, let’s try out a live demo
[5:33] I’ve set up a very simple device here, we’ll use the chrome dev tools to try and connect to it.
[5:38] Chrome has some quite useful BlueTooth tools and we should be able to find our device if we start scanning.
[5:46] It can be quite hard to actually find the device as there can be a lot of BlueTooth devices around.
[5:52] If we search for our device name then we can find it.
[5:56] Then we can drill into it and see what services it offers up.
[6:00] I have a very simple service with three characteristics.
[6:03] And I’ve added some human-readable descriptions.
[6:06] So we can read this description and see that we have the red channel.
[6:10] So if we write to this channel we can turn on the red light.
[6:19] And we can turn it off as well.
[6:21] Similarly, I have a green channel, so I can send a value to this.
[6:28] And also turn it off.
[6:33] And we have the blue channel as well.
[6:43] So that was interesting, but here’s a custom app I’ve made that has
[6:47] some sliders that talk to the hardware.
[6:50] So we can see it’s pretty easy to control the brightness of each channel and we can get some quite nice colors.
[6:55] That was a pretty simple example - there are some challenges of course.
[7:00] One of the companies I work with produces these educational robots.
[7:03] One of the problems with BlueTooth devices is that you don’t really know which one
[7:07] you are connecting to.
[7:08] Imagine a room full of 20 or 30 children all with robots, all of them connecting to random
[7:13] robots - it would be carnage.
[7:45] BLE is designed for low power, one of the trade-offs that you generally make to get
[7:49] low power is performance.
[7:50] In the case of BLE when we talk about performance we’re talking about transmission speed and
[7:56] range.
[7:57] Typically you are sacrificing both of these when you go low power.
[7:59] However, there are use cases where you do need to transmit a large amount of data on
[8:04] BLE - a typical use case would be doing a firmware upgrade where you might need to transfer
[8:09] a few hundred kilobytes of data.
[8:11] Just how fast can we transmit data over BLE?
[8:15] At this point I really have to acknowledge a couple of blog posts that dive into this
[8:18] in detail - I’m just going to summarize them as I’m not going to pretend to have
[8:22] anywhere near the expertise of the blog authors.
[8:25] The first is from 2016, so it’s a little bit out of date, but it’s full of really
[8:29] interesting information.
[8:31] The second is more up-to-date and really dives into the details.
[8:34] Both of them are definitely worth reading.
[8:37] So what are the limits on our throughput?
[8:39] We have a pretty fundamental limit in Bluetooth 4.0 of one symbol or bit per microsecond.
[8:45] This puts an upper bound on the throughput of 1Mbps - it’s not possible to go faster
[8:50] than this.
[8:51] We then have a 150-microsecond gap between each data packet.
[8:55] There’s an 80-bit ACK packet for every data packet.
[8:58] And then as always, we have the overhead of the protocol we’re using.
[9:02] You might be wondering why we need to have a 150-microsecond gap between packets.
[9:06] Well, BLE is designed for low-cost simple devices - when you are sending data the antenna
[9:12] heats up - this causes it to change its characteristics.
[9:15] The 150-microsecond gap gives it time to cool down which means your device can be much simpler.
[9:22] Antenna technology is completely amazing nowadays, if you’re thinking of your old-style TV
[9:26] aerial, think again, you can build antennas out of PCB traces and you have these amazing
[9:31] 3D fractal antennas that are absolutely tiny.
[9:34] So, protocol overhead, at the lowest level we have link-layer packets, these have an
[9:40] overhead of 14 bytes and a maximum payload of 27 bytes.
[9:44] Sitting on top of the Link Layer packets we have the L2CAP Packet - these have an overhead
[9:48] of 4 bytes.
[9:50] And then on top of all of this, we have Attribute Protocol Packets.
[9:54] By default, these have a payload size or MTU of 23 bytes - this lets them fit inside one
[10:00] Link Layer packet.
[10:02] By increasing the MTU you can increase throughput by removing some of the protocol overhead.
[10:08] But the theoretical maximum you can do is 0.3 Mbps.
[10:13] So that’s what we can do with BlueTooth 4.0, but technology doesn’t stand still, there
[10:17] have been several improvements to the spec.
[10:19] The first came in version 4.2 - this let us extend the data payload in the link layer
[10:24] packet from 27 up to 251 bytes.
[10:27] This can give us a throughput of 0.8 Mbps
[10:32] The next improvement came in version 5.0.
[10:34] This lets us increase the symbol rate to 2Mbps giving us a potential 1.4 Mbps.
[10:41] So, pretty impressive, it looks like BLE is all we’d ever need.
[10:46] Well, BLE is great when want to have a device that is used by one person at a time like
[10:50] a remote-controlled robot, or a heart monitor.
[10:53] But sometimes we need something that can be a bit more autonomous or can be controlled
[10:56] by multiple people.
[10:58] It’s also short-range, you can only use it when you are close to the device.
[11:03] The device can also only talk to other bluetooth devices - it can’t reach out to the internet
[11:07] and pull down data for itself.
[11:09] There are also the issues of the software stacks - these generally work, but can be
[11:14] quite buggy, for a long time the Android Bluetooth APIs were a complete disaster.
[11:20] You are also at the mercy of the hardware manufacturers and their Bluetooth stacks.
[11:24] So getting anywhere near the throughput performance I mentioned earlier is unlikely.
[11:29] The other thing that I should mention is that although the link layer of the BLE is a reliable
[11:33] protocol a lot of BLE stacks will silently discard packets if they are overloaded or
[11:37] if there is contention for resources - so if you are streaming large amounts of data
[11:42] you may need to build your own reliable protocol on top of BLE.
[11:45] So, let’s talk about WiFi - this will solve all our problems.
[11:50] First off, let’s look at some of the hardware options, there are some really nice modules
[11:54] you can use - a really popular one is the ESP32.
[11:58] This is a dual WiFi and Bluetooth module, it’s a really beefy module with a 240MHz dual-core
[12:04] CPU - you can definitely use this as the basis for your entire product.
[12:08] As with the Bluetooth module we saw earlier it comes with a lot of built-in peripherals
[12:12] and once again if you need to you can couple the module with a more fully featured processor
[12:17] and just use it to provide WiFi and Bluetooth.
[12:20] So, the hardware is easy.
[12:21] But there are some really big challenges:
[12:24] Most devices we’re talking about don’t have a keyboard, and they usually don’t have a
[12:27] screen either.
[12:29] If you are lucky you might have some indicator LEDs.
[12:32] We don’t really have any way of entering the WiFi credentials.
[12:35] And, even if we can get the WiFi credentials set up, there’s no easy way to know what
[12:39] IP has been assigned to the device - which makes it quite difficult to do anything with
[12:43] it.
[12:44] Let’s deal with the first challenge - what are our options for configuring the WiFi?
[12:49] If you’re flashing the device yourself then this is pretty easy - if you’ve used a RaspberryPi
[12:53] then you’ll probably know about the configuration options when you burn a new version of the
[12:57] OS to an SD Card.
[12:59] We can tell it the WiFi credentials and set up the user and password for an SSH connection.
[13:05] But if you’re shipping ready-made devices to your customers then you’re going to need
[13:08] some other way of setting them up.
[13:10] Now, most routers do support WiFi-protected set-up or WPS in some form.
[13:15] You push the button on your router and then a device can automatically connect to the
[13:19] network.
[13:20] However, a lot of security-conscious people disable WPS as it’s potentially very insecure.
[13:25] If you are in any kind of corporate or office environment it will definitely be disabled.
[13:29] There’s also no guarantee that it will work.
[13:32] And I think we’re all aware of how bad most WFi router firmware is.
[13:36] Another option is to combine Bluetooth and WiFi - you use the Bluetooth connection to
[13:40] configure the WiFi settings and then once that has been done you switch over to WiFi.
[13:44] This can work quite well, but it’s quite a lot of extra work and you do need to use
[13:48] a module that supports both protocols such as the ESP32.
[13:53] The route that most companies take is to have the device start-up in configuration mode.
[13:57] The device creates its own Access Point with a Captive Portal.
[14:01] You then tell your customers to connect to the access point and present a form for them
[14:04] to configure the WiFi credentials.
[14:06] Let’s show that in action with another live demo - I’ve got this LED matrix here that I can put into configuration
[14:13] mode by double clicking the reset button.
[14:15] When it’s in configuration mode it creates its own Access Point that we can connect to.
[14:20] The AP automatically takes us to a web page where we can configure the wireless network.
[14:26] Once it’s set up it will connect to the network and we a nice little screen showing
[14:30] us its IP address.
[14:31] But let’s face it, the majority of the devices we’re dealing with don’t have a screen.
[14:35] So we’ve got a bit of a problem.
[14:37] Our device is connected to our WiFi network but, we don’t know where it is.
[14:41] We’ve got some options.
[14:43] You can get clever and blink out the IP address - but let’s face it, that’s not very usable.
[14:48] This video is just the device blinking a count of each digit of the IP address.
[14:52] But I’ve seen some examples where people have used morse code to blink out roman numerals
[14:56] - it’s a solution, but I’m not sure it’s the right one.
[15:00] We can use a fixed IP Address - this is a great solution, but it’s really only suitable
[15:05] for people like us who can mess around with their routers and requires a level of technical
[15:09] competence that the majority of people don’t have and honestly don’t want to have.
[15:14] Our next option would be to use something like Multicast DNS.
[15:17] This is the technology that underpins bonjour.
[15:20] It works by broadcasting a query over the network asking for the IP address of a hostname.
[15:25] If a machine on the network has that hostname then it broadcasts a reply.
[15:29] I’ve used Wireshark to capture an MDNS query and response.
[15:33] Here we can see my computer asking what the IP address of matrix.local is.
[15:38] That query gets broadcast to every machine on the network.
[15:41] And here’s the reply - it tells us the IP-Address and it also tells us how long we should cache
[15:46] it.
[15:47] MDNS works really well, but for quite a long time it wasn’t supported by Android - which
[15:52] really limited its use - it is now supported and if you were making a custom application
[15:58] then you could add support yourself.
[16:01] The last alternative would be to implement your own discovery mechanism - but you’ll
[16:05] find as you start to do this that you’ll end up reimplementing MDNS - so ultimately
[16:09] pretty pointless.
[16:10] These limitations are often why we see companies creating gateways for their hardware on the
[16:14] internet.
[16:15] It’s much easier once the hardware is connected to your WiFi for it to talk to a server in
[16:20] the cloud.
[16:21] Your user will then just go to their account and add whatever hardware they have purchased
[16:24] to it and it will magically start working.
[16:27] This opens up a whole new world of possibilities as you can now access your device from anywhere
[16:31] in the world.
[16:32] It’s also a lot easier to automate it with other services such as If This Then That.
[16:37] But it does come with a whole host of security and privacy issues.
[16:41] And you now need to maintain a server as well as some hardware firmware and probably a custom
[16:46] app.
[16:47] Now we talked previously about the tradeoffs with BLE and power consumption.
[16:51] Things are different with WiFi - it’s not really been designed with low power consumption
[16:55] in mind.
[16:57] With the ESP32 we’re looking at around 50mA jumping up to 0.3 amps when transmitting over
[17:04] WiFi.
[17:05] So with our 2000mAh battery, we might be able to get about a day or so of runtime.
[17:10] However this really depends on our application, deep sleep mode can go down as low as 10 microamps,
[17:16] this little weather display uses an e-paper display and only wakes up every hour to get
[17:21] a new forecast.
[17:22] It runs for about 4 months on one of these 1000mAh batteries.
[17:27] Pretty impressive stuff.
[17:28] So, those are the two obvious options for talking to hardware - Bluetooth and WiFi.
[17:34] Both have strengths and weaknesses.
[17:36] Bluetooth is great, it doesn’t require any setup or infrastructure and you can easily
[17:40] build apps that can connect to your hardware.
[17:42] There’s also support coming to browsers - it is still locked behind experimental flags
[17:46] and only supported by a few browsers, but wider support is inevitable.
[17:50] The downside of Bluetooth is that it only works if you are close to the device and it
[17:54] is only suitable for one user at a time.
[18:00] WiFi opens up a lot of other possibilities, if you have a WiFi-enabled device connected
[18:04] to your network it can pull in data from other services and it also gives you the potential
[18:09] to control it from anywhere in the world.
[18:12] The downside of WiFi is the additional complexity of getting it set up and the fact that it
[18:16] does need a wireless network to connect to.
[18:19] So how about some more alternative solutions?
[18:24] Back when we had headphone jacks a few companies produced hardware that plugged into them - does
[18:28] anyone remember Scentee?
[18:30] It was a little device that plugged into the headphone jack and generated a smell.
[18:38] For a while, there was quite a bit of active development in this area with people building
[18:42] small break-out boards that harvested power from the audio jack along with data transmission.
[18:47] Pretty bonkers stuff.
[18:48] Obviously, nowadays we don’t have headphone jacks, but people are still making use of
[18:52] audio to communicate with the hardware.
[18:54] One of my friends has used this technique to solve the problem of setting up WiFi
[18:57] Let’s have a quick look at this in action.
[19:14] Brings back memories of the old dial-up days.
[19:17] There are also people using light to transmit information - here’s a system called BlinkUp
[19:22] in action.
[19:40] So, what does the code actually look like - it’s surprisingly easy to get connected
[19:45] to a Bluetooth device.
[19:47] You start off using the CBCentralManager.
[19:50] This needs to do a bit of setup - which may involve asking the user for permission to
[19:53] use Bluetooth.
[19:54] If all goes well then it will call back to you and tell you that it’s powered on.
[19:58] You can then tell it to start scanning for peripherals.
[20:00] You can ask it to just find all the peripherals nearby or you can ask it to only find peripherals
[20:04] that are advertising a certain set of services.
[20:07] As it finds devices it will call back to you with each device it finds.
[20:10] Typically, you’d present this as a list to the user and get them to pick the device
[20:14] that you want to connect to.
[20:15] Once you’ve picked the device you ask the central manager to connect to it.
[20:20] You can now interrogate the devices for the services and characteristics that it offers
[20:23] and you can read and write from those characteristics.
[20:26] I’m not going to show the actual code - there are plenty of examples out there for you to
[20:29] look at and you really just need to understand the flow that I’ve outlined.
[20:33] It’s definitely worth digging into the docs to see what’s possible.
[20:36] What does it look like from the actual device’s point of view?
[20:40] Here things are a bit more difficult - it will really vary depending on the hardware.
[20:44] If you’re looking to play around with something simple then the Arduino platform is a good
[20:48] place to start.
[20:49] It’s pretty simple.
[20:50] We create a BTLE server.
[20:52] Add some services to it
[20:55] Add some characteristics to the service
[20:56] And then we just start advertising to the world.
[20:58] It really is just a few lines of code - or maybe it’s too much code, let me know in
[21:03] the comments.
[21:04] So, more about PCBWay - they’ve been sponsoring the channel for some time now and I’ve had
[21:10] quite a few PCBs manufactured by them.
[21:13] They also offer CNC and 3D printing - we’ll be doing a couple of projects with that in
[21:17] the near future.
[21:18] Check out the link in the description.