Tuesday, March 26, 2019

Android BLE Integration (Nearly)

Things slowly came together this past week for adding Bluetooth Low Energy (BLE) capability into the Android Boat Captain software. I used Android Studio on my wife's computer for a day to do this, but found it a bit cumbersome to drag my electronics and USB cables back and forth between my laptop and her computer. This prompted some browsing of new computers on the Internet for a couple of hours, but this exercise revealed that the computer I wanted to buy was over $1000 so plan B was to try installing Android Studio on the Mac partition of my hard drive, to see if it fared any better than it did under Windows. Lo and behold it did!!! It was pretty much as fast as it was on my wife's computer, and didn't suffer any of the same debugging problems that I had under Windows. Why it performed so poorly under Windows, I'm not sure. Maybe it was general Windows 10 slowness, or the 2000 or so things that always seem to be running in the background, I don't know.

Anyway, I was able to make some steady progress after that. The reason I wasn't receiving any BLE traffic before was that I had to wait for a notification that data had arrived in the Android code. The process for requesting and receiving BLE data is somewhat convoluted. The literature claims that the reason for this is to conserve power. That may be so, but it sort of seems more complicated than it needs to be, as there are a number of steps involved in setting up a connection, more steps involved for sending out data and verifying that the data was really sent, then steps involved for enabling notifications for the receipt of data, and then finally actually receiving the data when it does arrive. Plus, the data arrives in little chunks that are no more than 20 bytes in size, so the actual data packets have to be stitched back together afterward. The 20-byte packet size and notification-based-approach also makes data transfer a bit slow; unless I can figure out some way to reliably speed it up, it'll be like travelling back in time 30 years to the days of dial-up modems. The slow speed is fine for simple control commands that only require a few bytes, but makes things like image downloads pretty slow.

Everything communications-wise is almost all working now. The commands for controlling propeller power and direction, and requesting basic sensor data all work, but some of the more complicated commands for requesting image samples and / or bringing the boat back to the GPS location of the phone need a bit more work. After that I'll switch over to iOS and do it all over again...

Tuesday, March 19, 2019

BLE Beginner

Last week I was optimistic about getting some Android and iOS software done for establishing a Bluetooth Low Energy (BLE) connection to the RFU220 wireless unit that is used for long-range communications with AMOS. Unfortunately things didn't turn out as nicely as I had expected. The latest BLE libraries for Android required that I download and use Android Studio for my development work, rather than the tried and tested "Eclipse" software that I have been using for the last 6 years or so. A couple of days were required for downloading and installing Android Studio, porting over my project files for the Boat Captain software, and figuring out how the new build scripts (Gradle) work for actually compiling my application. Android Studio tends to run very slowly on my 7 year old MacBook Pro (running Windows 10 32-bit), or in some cases not at all. In order to build and debug the Boat Captain software, it actually needs to allocate 1 gigabyte of memory for the Java Virtual Machine (JVM) and about half the time my computer seems to balk at this step and requires a reboot or two before it decides it can afford to shell out that much memory. Boat Captain is by no means a large application; I think Android Studio just always decides to take that much memory for the JVM when debugging.

This morning I secretly installed Android Studio on my wife's computer (i7 processors with 16 gigs of ram and a solid state drive) and may continue the rest of my Android development work on that computer when she's not around. Things are definitely a lot faster on it!

The actual BLE code development for Android is going slowly too, mostly because it's all new to me and I don't really know what I'm doing. Good examples on the Internet are kind of hard to come by, and the official documentation for these libraries is a little bit short on details sometimes. However, I have so far managed to at least send data to AMOS through the BLE connection; just haven't figured out yet why nothing is coming back. I'm sure it'll all get sorted out eventually though. And when it does, it'll be awesome! 😎

Tuesday, March 12, 2019

Enclosures and Extenders

The turbidity sensor enclosure that was described last week was completed this week, and a quick test in a shallow sink of water did not show any leaks or bubbles, so it looks like it will do the job for actual surface water turbidity measurements. It was 3D-printed in 3 sections, with O-rings between the sections and a cable gland on top for routing the power and data wires back to the rear enclosure of AMOS:

There is a small hole on the bottom for water to flow in and out of. Possibly this hole might need to be widened a bit, if it happens to get routinely plugged up with debris. The hole should be as small as possible though to prevent stray ambient light from interfering with the sensor readings.

Also this week, I got a small Bluetooth Low Energy (BLE) circuit board, the HM-10 that I wanted to hook up to the RFU220 radio that I am using to communicate with AMOS. The idea was to allow a smartphone to communicate to AMOS over the long range wireless RFU220 (up to about 3 miles according to the spec from Synapse). Smartphones do not typically allow cables to be plugged into them, so some sort of local wireless link (WiFi or Bluetooth) would be required to connect to the RFU220. The HM-10 that I got was pretty inexpensive (~ $5) so I figured it was worth a try. At first though, nothing seemed to be working. An LED on the HM-10 would turn on and blink at a 1 Hz rate, but that was it. After about 2 days of pouring over various manuals and Internet posts, I was eventually able to determine that I did not in fact have an HM-10 (although it was advertised as such on Amazon) but rather one of the many knock-offs that various companies have produced over the last 5 or 6 years. After some more searching through manuals and Internet posts, I was finally able to get it working, at least with my Android phone. I haven't tested it on the iPhone yet, but I'm assuming that that should work too.

The plan is to put these boards:

inside a small waterproof case that I won as a door prize a few years back. I'll need to add a small hole for the antenna, and will probably want to glue some pieces to the outside of it for mounting the smartphone. And I'll need to add 2 or 3 AA batteries inside the case too. The interior should still be waterproof, even with the antenna hole, and should also be able to float, so the phone won't sink if I happen to have a spill in the kayak.

Tuesday, March 5, 2019

Ready For Pool Test #2

I learned this, at least, by my experiment: that if one advances confidently in the direction of his dreams, and endeavors to live the life which he has imagined, he will meet with a success unexpected in common hours. He will put some things behind, will pass an invisible boundary; new, universal, and more liberal laws will begin to establish themselves around and within him; or the old laws be expanded, and interpreted in his favor in a more liberal sense, and he will live with the license of a higher order of beings. In proportion as he simplifies his life, the laws of the universe will appear less complex, and solitude will not be solitude, nor poverty poverty, nor weakness weakness. If you have built castles in the air, your work need not be lost; that is where they should be. Now put the foundations under them.
- Walden or life in the woods,  by Henry David Thoreau

As advertised, the DS3231 real-time clock (RTC) was very simple to setup and get working with the Pi, and no programming was required. Just had to wire it up, modify a couple of configuration files, and then re-boot the Pi. Now I don't have to worry about getting an accurate time from a time server after re-booting before saving data or log files. Also, the added bonus of the RTC is that it seems to have cleaned up some occasional errors that I was getting on the I2C bus. The RTC device is on the same bus, but I removed the termination resistors from it, so I'm not sure why it would have any effect on the data quality of the other devices (inertial measurement unit (IMU) and analog to digital converter). Previously I had been getting errors (mostly from the IMU) maybe about 1% of the time, but now the errors are gone. Maybe some subtle difference in line termination or voltage levels that magically made things better.

Some additional bugs (mostly related to multi-threading) were uncovered and fixed in the Boat Captain PC software. I also modified things a bit to filter out some commands sent from the PC to the boat if a large number of them were sent in rapid succession. This helped a bit to improve the responsiveness of the remote control interface. I also updated the Android and iOS versions of the Boat Captain software, to add support for the humidity, current, and wireless received power measurements.

I have re-visted the idea of creating a waterproof enclosure for an inexpensive turbidity sensor. The inexpensive sensor basically seems to work if care is taken to shield it from ambient light and make the top part of the sensor module (where the wires plug in) waterproof. A quick 3D-printed test part indicated that it should be possible; I'm not sure if my printer is up to the task of creating a full-size enclosure though. My first effort ended in a large messy blob, as the printer generally tends to mess up on large pieces. I'll try breaking it up into separate pieces that are bolted or screwed together with O-ring seals. If that doesn't work, maybe get a printing shop to do it.

Tomorrow is another pool test, and I want to try out the new air propeller / steering mechanism. I'm also planning on setting up some short automated routes in the pool to see how well it keeps direction. I'll post a video here tomorrow evening.

The test went well - AMOS can now steer quite ably. Here are a couple of videos showing a fast power turn and a more careful turn in the corner of the pool.