our swiss φθηνα ρολογια are all in now.
Some musings about connecting the remote device to the UI-UWP app.
Index of Articles
Next: RPI as the SurfPad (Bluetooth)
Prev: USB Serial Connectivity
Code Repository: (Github) djaus2/SurfPad
Ideally the remote system will run as a headless system, at least not require any user interaction. This requires two things:
- The remote system is able to automatically determine what connectivity state is required at startup.
- The remote system is able to automatically connect to the UI using that connectivity mode.
The original terminal apps, Bluetooth, USBSerial and Sockets required the user to select from a list, the device to connect to then to connect. The desire is to remove the requirement for this intervention.
So the requirement is for the connectivity for the desired mode to be automatically set up and connection to be actioned without user intervention,
The remote system will need to start in one of the three modes (BT, USB, Socket) without user runtime intervention. This could be achieved by setting the mode in software and recompiling. A better alternative is to interrogate some hardware settings at startup using the same prebuilt remote binary, to determine the required mode. This has been implemented in both the Arduino and UWP (Remote) code by inputting 3 GPIO pins with one and only one being set high, so determining which mode to adopt. The Arduino pin inputs, as configured are pulled low and only read hi if jumpered to Vcc and so only one jumper is required. (A0, A1 and A2 are used for BT, USB and Sockets respectively). The IOT-Core GPIO requires all three GPIO inputs pins to be set to a determined value and so three jumpers are required. GPIO2, 4, 6 are used (pins 3, 5, 7) for BT, USB and Sockets respectively.
Having established which connectivity mode to use, the remote app then has to choose which device to connect to. For sockets, this is not an issue as the remote end is the socket server and so it just waits until a socket client (the UI app) initiates a connection.
With USB Serial the connectivity is straight forward for the Arduino device. The USB connection to it that is used to program the device can also be used for this connectivity. For the RPI remote device, a Sparkfun FTDI Breakout unit was used with the native UART on pins 2 and 3. This component does not require a device driver at the RPI end as it takes the UART signals at TTL level (works with 3.3v levels via an onboard switch) and encodes them a USB Serial for communication to the UI UWP app.
With Bluetooth, Bluetooth Serial requires both ends to be paired. The pairing needs to be initiated from the UI end which with Arduino is desirable, but becomes problematic with the RPi IoT-Core. (More on this later). Also, there may be more than one suitable device paired with the endpoint. In the simplest scenario, if there is only one paired device available then that is what is connected to. Where there are more paired devices the code can be modified to accept one device that contains a specific string within the paired device’s Device.Id. If “DEV” is in that string then it’s the Arduino device. If using a RPI as the remote device then “SPP” is used.
The Bluetooth connectivity to the remote device works fine for the Arduino device. The problem with using Bluetooth connectivity between a UWP app and a RPI running IOT-Core is multifaceted: Firstly the Bluetooth in the RPI3 is LE only and does not support BT Serial. When disable and replaced by a suitable USB dongle we run into a problem that pairing has to be initiated from the RPI device. You can’t then assigned a serial port to that connection. My solution is to turn the BT Serial wrt a RPI into a simple serial model wrt the RPI. By connecting a BT device such as the Sparkfun Bluetooth Mate (there are several, I used Gold) to the RPI3 UART the architecture appears to simply serial from the RPI end but from the UWP end IS Bluetooth Serial!