Just Harmony

                                                                                                                                                                                        Designed by Freepik
 Well after a few weeks of work,   I may be there.  The software component lefty to implement is the script manager.  This is mostly software with a dependency on the Non-Voltaile Memory driver.  Since that is working with the config data, what remains is verifying it works on the larger memory needs of the script manager.

The last problem child was the Bluetooth and the RN487x interface.  First the UART driver did not work anything like the previous model.  As a result the Tx function is blocking, kind of, for now.  Not sure how important that is.  In the RN487x implementation, I wait around for the CMD prompt before executing the next instruction.  I could have the ISR process the flag the main loop when this happens, but this is only important on initialization.  For now I am just going to leave it as an inline process that runs to completion.

The Rx function works like before with an ISR that processed the Rx queue from Harmony.  I did have to use the Ring Buffer  implementation.  The normal implementation required that you submit a read request, instead of just using the call back when a byte came in.

There was another problem, but this had to do with Android software  I had thought I had solved this problem several years ago, but it came back.  It has to do with how many bytes are transmitted when writing a Bluetooth Characteristic.  Once transmit 8 (the maximum I set up), then in that session it will always transmit 8.  If you send 4 bytes, it will just stuff the other 4 bytes with the last 8 byte transmission.  You can read about this issue here.

Time to move on and finish this to the point I can start to assemble the new PCBs.  I have a place for at lest on of these 15 channel LED controllers.

 

Windows 11 Upgrade

 

Well it was time to upgrade to Win11 on at least some machines.  Taking a big gamble, I did my file server first.  Surprisingly this went very smoothly.  All of the Win 10 machines still had access to files and printers.  Next was my main development laptop.  Again it went smoothly until I tried connecting to one of my HID devices.

In this post from September 2021 and the followup in October 2021, I talk about issues I had with the Jedi JVC Controller software for HID control in Delphi.  These issues only applied to my HP Elitebook 850 G5.  So tracing back into the JEDI HID controller source, I found where the error handler was being raised and then what HID device was failing.  As before it was "HID Sensor Collection V2".  Again it was not showing up in the standalone Microchip HID Test program.  The Jedi HID code indicated that once again it was failing the get attributes call to the Windows HID.dll.  Finally the JEDI HID code would raise the "Device cannot be identified" error.

But under HID devices in the Device Manager this was not listed.  Last time I had changed the HID driver to a generic HID controller and that fixed everything.  After searching around, I noticed a sensor category in the Device Manager and that is where it was.  Changed the driver to Generic HID and the error went away.  

What I did notice is that the error handler described in the second post above, was not present.  It looks like I did it on all the USB Power devices PC applications, but not for the Brick Controller.  So that is now implemented and all is as it was before the Windows 11 upgrade.

Is Windows 11 better, so far I don't think it is better or worse, just different😜

 

 

 

RN4020 to RN4871 Update

 

I have had my head down while trying to make this transition that I described briefly in this post.  I have had some success and learned a few things along the way.  

I am no BTLE expert and I have tried to slug through the specifications, but it is a tough read for those of us who don't do this on a daily basis.  The RN4020 was 4.2 and the RN4871 says it is 5.0 and beyond.  I am assuming that some enhanced features were added.  My Android code was quite dependent on this real time read feature of the RN4020.  Without this, getting data back was difficult.  

After some reading, I implemented the Notification feature for each characteristic.  I had done this with the Heartbeat characteristic, but now all of the characteristics have this enabled.  This will also enable me to continue to support existing Brick Buddy I controllers.  The Android APP tested to see if Notifications are enabled on the Brick Buddy.  If they are, the new code is implemented, otherwise the Android APP stays with the old methodology.  So now I write to the Characteristic, the 18F26Q71 performs the tasks, updates the characteristic value and then notifies the Android APP the characteristic has changed.  The APP is waiting (in a separate thread) for a few seconds for the 18F26Q71 to respond (plenty of time at 64MHz).

Next issue was finding the the Brick Buddy during scanning.  The Android APP had implemented a scan search on the MyMakerTools UUID.  While it continues to work for RN4020 devices, it failed on all RN4871 devices.  I could scan for it along with every other BTLE device in the house and the neighborhood.  Sometimes I would see 20 devices.  At first I thought this was an issue with the Delphi compiler.  After tracing deep into the library, I decided this was not the issue.  This must be something to do with advertising.  Again, not a BTLE expert and if the spec changed, then I was not seeing it.  I found a note in a RN4870/4871 firmware upgrade document that said:

This led to lots of reading on the NA command, which is about advertising.  So in the RN4871, you have to purposely advertise services.  If the Android APP is filtering on a specific service list, those services must be advertised.  If not filtering on a specific service list, then all reachable BTLE devices show up.  The system will still connect, but it is multi step process that should just happen.

So here is the initialization of the RN4871 across the ASCII UART interface.  Will another sequence work, probably, but I know this works.

• PZ
• NA,Z  

reboot here

• SS,80            ; setup
  
• SN,B-Buddy       ; device name
  
• SDN,MyMakerTools ; mfg name
  
• PS,3425a5cca67643629592a88e132b8b52       ;service
  
• PC,b67e3a3b15c941b6a9f2fbf379418d12,12,02 ;characteristic
  
• PC,f18e901af3254dfd8cdb68506676dc08,16,08 ;characteristic
• PC,9bac1d289fc14db097c4896089ad26bb,16,08 ;characteristic
• PC,39bb1bf917ec41d2b5e4b78551b45740,06,08 ;characteristic
• NA,01,06         ; set flags
  
• NA,07,528b2b138ea89295624376a6cca52534    ;advertised service
  
• A                ; turn on advertising
  

 The first two clear out the services/characteristics and the advertisement data, followed by a reboot.  The next are setup and naming, followed by the service and the characteristics.  The first NA command sets the flags.  The first hex value is the AD Type which is found in Table 2-14 of the RN4870/71 Users Guide.  The next is an 8 bit value that reflects which flags are active.  You will need to search the internet to find this, but 0x06 is the most common value.  The last NA command is the advertised service.  You will notice that is does not match the service.  For whatever reason, the NA, 07 command will not take the value as the PS command does, it needs to be completely byte swapped.  Not the most user friendly, but probably made sense to someone.  Finally I purposely started advertising.  This is supposed to be the default, but it costs very little.  I did not test the initialization without this, so I don't know if the default is works also.

I am back to where I was with the RN4020.  I still need to verify the Android APP with the original Brick Buddy, but that is a task for another day.

 

 

Android 12 & Delphi 11.2

I finally got around to updating my three Android Apps for API 32/ Android 12.  So to start this blog post off, the following Apps are now available:

 

T-DUST  is a small module to monitor the  temperature in your Maker projects.  The app provides all the control  functions for a T-Dust device.  This includes displaying in Fahrenheit  or Centigrade, setting the data rate, recording to internal memory and placing the device in the power down collection mode.  The module has a 32Mbit memory on board for recording temperature data.  The app will  chart the temperature data on the mobile device or convert to a CSV file  for download. The module can record for over 120 hours at a 1 second  rate. 

 

The Power  Monitor is a small monitor module that plugs in between the USB Power Modules and your application.  The USB connection provides a constant  reading of the voltage and current on all of the voltages (12VDC, 5VDC  or VUSB, 3.3VDC, 2.5VDC and 1.8VDC).  The PC program provides all the  control functions and will keep a record of the voltage and current.   The module also has a 32Mbit memory on board for operating in the stand  alone mode.  Power comes from the Port 1 connection.  You can record up  to 65000 records, which is over 18 hours at a 1 second rate.  There is  an optional BT connection for controlling the monitor.  We provide the  API for both USB and BLE so that you can create your own custom  applications.

 

This is a dedicated brick controller for running your platform  designs. This  controller is dedicated to the task at hand.  Using a simple Android  mobile interface over Bluetooth, the sequence of up to 4 motor  controllers can be setup.  Additionally there are 4 LED lighting control  lines for dramatic lighting effects.  Finally it has three inputs for  sensing different types of real world events.  A Windows PC input setup  is in development and future versions will have an audio amplifier to  provide a single source for controlling your MOC.

Getting here did have some issues.  There were major changes to Android BT permissions.   You can see the changes here. Delphi will automatically generate the Manifest for you based on settings in the Project Options menu.  But this is very basic.  What is needed in some cases, especially Bluetooth implementation, are the qualifiers that go with the manifest entry.

Basically in Android 12 they introduced a SCAN, CONNECT, ADVERTISE permissions and eliminated BLUETOOTH and BT ADMIN.   Though what Google does not say is the ACCESS_FINE_LOCATION permission is not needed anymore, though it was never clear in the docs that it was needed prior to Android 13.  What you need for the basic private BT connection is

<uses-permission android:name="android.permission.BLUETOOTH" android:maxSdkVersion="30" />

<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" android:maxSdkVersion="30" />

<uses-permission android:name="android.permission.BLUETOOTH_SCAN"  android:usesPermissionFlags="neverForLocation" />

<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" android:maxSdkVersion="30" />

 Unfortunately there is no way inside of Delphi to add these qualifiers, ie android:maxSdkVersion=30.  What I did was modify the AndroidManifest_Template to include these lines.  Then in the Project Options men, I made sure these options were deselected.  This way Delphi will not generate these permissions in the android manifest and all will work as expected.  You can find more information about this at the Delphi forums, here.  You may need a guest login to see the thread.

 
 
 

Android Updates

Well once upon a time, it was very easy to develop, test and push into the PlayStore.  I guess Google became jealous of Apple and its layers of requirements.  At som epoint I do understand that they need to have standards, but these updates every year are time consuming for the single person developer.   I spent the last 3 days trying to move one app (TDust) into the play store.  Now part of it is truly my fault for not keeping the apps up to date.  So trying to move from API 24( #7) to the new required API 30 (#11) and 64 bit versions has been fun. I can test on Adroid 7,8,11 and 12 with the devices I have.  I actually went to Best Buy and bought an unlocked phone.  It was $165 if you activate it and $165 if you dont.  Naturally I did not activate.  It is more a less a mini tablet.

I had already done the Permission thing before, but Google keeps changing the permissions required.  When permissions were implemented, to use BLE you need to have location permissions. I suppose it is because there is small possibility that the location of the phone can be determined.  But this changed as the APIs advanced.  First it was coarse location then fine and now coming in API 31 (#12) no location as long as you swear on someone's grave you wont use BLE to find the phone's location.  Actually they are completely revamping the permissions around BLE it looks like.

I am only complying with API 30 and the new App bundle requirement for now.  This is good for new apps until Aug 2022 and Updates until Nov 2022, at which point it is API 31/32.  With the price of gas, I assumed I would not be making many trips this summer, but that did not happen as we were gone much more than planned.  

When I went all the way to API 30, it all failed big time.  The program crashed, the debugger failed, it was a mess.  So I went back two revisions on the Embarcadero Delphi compiler, API 24 and the last set of code that worked from SVN.  That worked on all the devices, though Android complained a lot when installing on the newer devices. So I slowly marched up the API list.  One thing I did was create a separate code module to handle the permissions.  That way once I figured it out, it would hopefully work for all my programs.  When I got to API 29 (#10) I had to switch the compiler version, since the older version did not support API 29(#10).  This is where permissions started changing and I had to research what was happening.  After two days I finally got it all working on API 29.  I am now one step away.  At this point I had to move to the latest version of the compiler.  This caused quite a few library types to change, but I was smart enough to implement conditional compilation so that I could go back and forth on the compiler versions.  This proved useful as API 30 did not come easily.  But after a day of searching and changing, the app finally worked on all the devices with API 30 as the target.

Then uploading to the Play Store became another fun thing.  You cant upload APKs any more they have to be in the new App Bundle format. And now signing/encrypting the App is not good enough, the upload has to have a key also.  They can be the same, but they recommend against it.  Well I converted my existing key to the format they wanted but could not figure out how to generate a separate upload key.  So for now they are the same.  Supposedly I can change the upload key, I just cant change the App key.  I uploaded the app and then the Play Store went nuts about a permission, background location.  I had read the it was now required, but they wanted to know why I was using and to provide a 30 sec video showing how it was used.  Then a week or so they would get back to me.  So I deleted the upload, went back removed the permission and tested again.  It all seemed to work.  Upload this new version, no complaints and it was published.

But it cant end here.  I then tested the install on the devices. The older devices were still installing the older version, don't know why.  Something I have to look into.  But the 64 bit version just crashed on start.  So back to the devices.  The compiler keeps separate configs for debug and release.  I had failed to test the 64 bit release version.  Found a setting in the 64 bit release config that was wrong.  Once that was fixed, the 64 bit devices started working.

I still need to find out why the new 32bit version is not installing.  You would thing this is not a big deal, but............  The Samsung A13 I bought at Best Buy is an ARM8 64 bit, but they installed the 32 bit version of Android.  So even if Google is screaming 64bit to everyone, some of the big guys are still installing 32 bit OS, even on 64 bit ARMs. 

Next is the API 31/32 update due in Feb 2023 now.