Updating Android

So the last six weeks or so have been spent trying to update the Play Store to Android 15.  Every August this needs to happen.  While most updates are fairly mundane, for whatever reason this one was not.  

One reason was the compiler also made major changes in how it operates with Android.  Once I figured out what was happening there, then the debugger was having issues.  Part of this appears to be related to the latest version of OneUI on my S23.  

I was also operating under the constraint that the firmware in the hardware devices that out there, cannot be changed.  And there a lot of Bluetooth 4.2 devices, which is also a constraint.  In the latest versions, there is a lot more initialization/verification in the connection.  Plus it determines what version of the firmware is present and then loads the correct User Interface, based on this and what device is connected.

I also test with four devices with varying versions of Android, Samsung Tab A7, Samsung A53, Samsung A13 and a Samsung S23.  The Android version varies from 13 to 15.  

Well now that is done, I can move on to the next thing.

 

Loose Ends #4

 

For the last month or more I have been working on Software and Device firmware.  I have not posted because this work is extremely boring, except for a very few.  Last summer I embarked on a project to consolidate the all the device firmware and the PC/Android software.  It was extremely cumbersome to constantly have to make the same changes in multiple places.  But this project was much larger than I thought.  But it has made a huge difference in developing new features, since they automatically deploy across all the devices where applicable.

The PC interfaces are now going to be consistent as are the Android interfaces.  The device API will also be consistent.  If the feature is not available on a particular device, a special message will be returned to indicate non-availability.

These are the updated interfaces.  You can see the difference in the Light Buddy 2 interface at the top of the page and this one here.  Brick Controller ONE did not have PWM control of the LEDs or the Motors, so that functionality is not shown.  All the other brick and light controllers have some form of PWM.

More on these updates later.

 

 In between I have been working on the tera forming and landscaping of the plateau area.  While it is generally flat, there still needs to be some kind of terrain.  This takes a lot of plates and tiles to do.  Once the terrain is done, then it needs to be landscaped.

Finally I have been trying to get the first Light Controller up and running again.  When I did it the first time was right at the start of COVID.  Then all the parts disappeared.  Now that most are back, I am updating the design.

RN4020 to RN4871 Update 2

In this post and the follow on post, I discussed the changes I have made for this transition to the RN4871.   I am getting near the end of this being done.  After testing with a several Play Store Apps (Nordic, Silicon Labs, and Microchip) I found that the name I assigned to the RN4871 was not showing up in the scan.  Again in the RN4020 this was not an issue, the SDN command was sufficient.  But for the RN4871 or maybe the version of BTLE that is running, this is an issue.  Unless you know the MAC address, the user would have a hard time determining which device listed is the Brick Buddy.  It is not uncommon for me to see 10-15 BTLE devices in my lab.  Not sure where they are all coming from, but these is a lot.  

Well it became apparent from examining those devices I was seeing that had a name attached, they were placing this in the Advertisement.  The RN4871 has an Advertisement limit of 30 bytes (31 bytes in later firmware).  Fortunately I had 11 bytes left from 30. So I added the name and that brought me up to 27 bytes total.  But as with adding the service, you could not just put the name in as text, as here.

NA,09,B_Buddy  

The NA command requires the actual hex bytes that represent the name.  This is alluded to in the RN4871 documentation, but is not really clear.  The 09 is the command for the complete local name.  

NA,09,422D4275646479     

It seems that everything works now.  The Android App finds it, connects automatically and the name is displayed with the last two address octets attached.  The Android App does allow you to name the Brick Buddy device and then bind that name to the MAC address.  From then on, it shows the name instead of the MAC address.  A more user friendly approach when you have multiple Brick Buddy's in a MOC.

Final change will be a check to see if the  RN4871 Non Volatile Memory (NVM) is valid.  Not sure how to do this yet.  I am somewhat concerned that reloading the NVM on every restart will wear this out too soon.  Especially for the device(s) I use for development.  The easiest way is probably to place a flag in the PIC EEPROM (or I2C memory when it is installed) that indicated a valid NVM.  Thus when the NVM is written and all commands have been accepted, the flag would be updated.  I currently have a config word that is kept, I just need to add this to it.

 

 

 

 

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.

 
 
 

Light Buddy 1 - Operation

 

This video was taken with a standard HD Webcam (Logitech C922).  It does not do a very good job at closeups, which is why the device is slightly out of focus.  Additionally the LEDs, when on, tend to overwhelm the auto white balance.  One of these days I will get a better camera for this type of work.

This is a short video the Light Buddy 1 in demo mode.  Attached are the LEDs we sell in 1 x 1 and 1 x 2 plate format.  All of the LEDs have an integrated resistor.  Here is what is happening"

1.  The white LED in the upper left is on STEADY.

2.  The small blue LED left side center is in one of the pulsing modes.

3.  The purple LED in the lower right is in CyCLE mode then pulsing mode.

4.  The small blue LED on the lower left side is in CYCLE mode

5.  The green LED in the upper left is in STEADY then BURST mode.

Sometime later I will put together a series of videos that show the different LED modes that are possible.

 

Light Buddy - The PCB

 

Got my latest PCBs on Tuesday.  I knew before they arrived I had a problem.  I assumed (should be a four letter word) that PPS would allow any function on any PPS pin.  Well PIC18 may come close to that, but PIC32 does it in blocks.  So now I have 10 boards that are really not very useful.  Fortunately the USB and the console port could be used.  This one is very similar to the Brick Controller I cant build for lack of parts.  The Motor interface is missing and the BT (RN4871) is superset of the BT (RN4020) module on that Brick Controller.  The PIC32 is from the same PIC32MX family, just in QFP44 instead of a QFP64.  So this one is a high end LED controller with 15 LED channels.  I had previously mentioned this. 

I started pushing code into it, using the previous BrickController and MPLAB X Harmony Project I started.  Just in case the startup code for this PIC32 was unique.  Amazingly the USB HID came up right away.  I could not move data back and forth, but the PC recognized that a HID device was connected.  On the next day I was moving data and my Win10 App was talking to the device.  There were some USB connection issues.  They may have existed before I just never noticed them, but I decided to make this rock solid.  The PIC32 USB/HID implementation is more flexible than the PIC18 and this is OTG, which I am not using.  There are 3 state machines at the App level, two of them are callbacks from the USB/HID driver implementation.  The third is the real App level state machine.  It took a few days to get this working.  It was a simple matter of getting all three state machines in sync with each other and realizing that the two callbacks were actually running as the result of ISRs and those totally asynchronous to the App it self.

Once the USB/HID was working, merging in the other code for the other peripherals is easy.  Will need some conditional compiles, I dont like maintaining multiple code bases if I dont have to.

More later.

Light Buddy 1 - The Design

I have been working intermittently on a new Brick Controller, that I documented in multiple blog posts, this being one of them.  Well since parts are impossible to get, I moved on.  Got a quote from one of the robber barons for the LED controller (TI LP5569) with an MRSP at Digikey of $1.65 in qty 1.  They wanted $55 for an MOQ of 25.

Below is the result.  Not sure I can get everything for it right now, but it will be good enough for demo purposes.  There was no way I was going to build any of my new Brick Controller.  So I switched to an LED controller.  This is a subset of what the Brick Controller was, just no motor control.  This made power much easier since I did not need to make 9VDC.  The LEDs are powered from VUSB, ie directly from the USB bus.  The PCB is 48x64mm and is designed to fit exactly on a 6x8 LEGO plate. 

The differences from complete design freedom are:

1.  Had to put in a new BT module, the one I have been using (RN4020) is not available for years if ever.  MIcrochip does not appear to be upgrading it for BT 5.x spec from 4.2.  The BT SIG has deprecated 4.2 already and wont certify any 4.2 after 1/1/2023, according to the Microchip website when you look at the old BT module.  This BT module(RN4870/RN4871) is BT 5.1 but the smaller version cant be found, so I am using the larger version.  I have about 15 of these I bought months ago as a hedge.  They claim firmware compatibility, we shall see.

2.  The processor is a PIC32 of the same family as the new Brick Controller and I am hoping the firmware changes will be minimal.  There seems to be lots of these floating around.  Hopefully tomorrow they will still be there.

3.  If you look carefully you will see a small square IC (U1).  That is the LED controller (LP55231).  This a previous version, but is firmware compatible with the one (LP5569) I used on the new Brick Controller.  I bought 20 of these months ago from one of the robber barons.  For whatever reason they were only 3x in cost.  The biggest issue for me is that this controller is a source to the LEDs while the newer version is a sink.  While this might not seem like a big deal, it actually has large implications in the wiring of a LEGO display.  At least I try to minimize the number of wires running through a LEGO build.  Using 36-42 gauge wire, you want to minimize the number of wires that can break.  So in my case, I minimize the number of source wires since this is the common wire.   All my previous designs used an N-FET to sink drive the LEDs, that way I can parallel up multiple LEDs and not worry too much about the current load.  So I added N-FETs to the output of the LP55231.  I give up the current control the LP5569 provides, but I use PWM to control intensity anyway.  With the VUSB supplying the drive voltage, a 120 to 150 ohm resistor provides the necessary current to brightly light the LED.  When the LP5569 controller becomes available, those N-FETs and one resistor per channel will go away.

4.  I added 5 more LED channels using the 5 PWM controllers in the PIC32.  These would normally control the motors, but they work nicely with LEDs also.  So this gives me 15 LED channels, which sounds like a lot, but I can get very carried away with lighting effects.

5.  I added 4 inputs, 3 digital and one analog.  Though the analog can be made into a digital.  The 3 pin connector has 3.3VDC, ground and input to either a Schimdt Trigger or an unity gain OP-AMP.  This shroud provide all the input I can use.

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.

More Android Fun

In the post, Android Fun,  I described some of the issues I went through converting my first App to API30.  I am almost done converting the next two Apps.  While some of the issues were the same, a whole host of other issues and errors happened with these.  Here is a recap of my progress so far.

As I commented in Embarcadero's public JIRA, RSP-35804, I had problems converting existing Android Apps.  For those who do not have access, here is the text.

" I came here from RSP-35919 (Android 12 - Bluetooth LE discover devices - access to location). I was updating a BTLE app from API 23 to API 30 for the Aug 2022 deadline. I started with Delphi 11.1 and had the same issue. The APP would fail during initialization. I backed up to 10.3.3 and API 23 and verified it still worked. Then moved through the API levels one at a time, changing to 10.4.2 when needed, then 11.0 and finally 11.1 and API 30. Made the changes needed at each API level and compiler version. (Note: when the permission types changed in 11.0, I created conditional compiler code so I could easily go back and forth between 10.4.2 and 11.0). It now works. What I changed that allowed it to work on 11.1 and API 30, I am not sure. Tested on Android 7,8,11, and 12. Both 32 and 64bit. Again, I am only doing BTLE device discovery, not location."

I have now converted my second App which was a little more complex than the first one.  I had similar but different problems.  At one point I had an error in  FMX.Platform.Android, TPlatformAndroid.Create, on the line Activity.addListener(FActivityListener) which caused the App to hang with no Android error message,  along with the location error RSP_35804 and a few others.  I used the same basic process I describe above.  What I am beginning to think is that the issue is a combination of the Android Manifest, library update (as described here) and carefully reviewing the project deployment page.  Here is the closest process I have to a conversion checklist.

• At every API level change, delete both the Android Manifest Template and the Android Manifest.  Start fresh.  If you manually change this, make sure you save your changes elsewhere so you can update these later.  Since I had not updated in a while, I had to start with 10.3.3, you start with where it worked last.
• Make sure you clean the project before Building.  Then go look at the directory and see what is left.  You might want to delete whatever is left, unless it is a file that you specifically need to be included.  (See the next item and CLASSES.DEX)
• Carefully review the Project Deployment Options Page (PROJECT->Deployment) in all configurations (32 bit, 64 bit, DEBUG and RELEASE).  This is especially true when going to version 11.x.  The CLASSES.DEX file moved from the DEBUG/RELEASE directory to a <projectname>.classes sub-directory.  Going back and forth between 11.x and 10.4.2 can orphan the CLASSES.DEX and I think this is causing issues.  (What I dont like is you cannot delete anything on this page that the IDE inserted.  So if you have been carrying this project since 10.0 or before there can be a lot of excess baggage.)
• When you get to version 11.x, it is imperative that you update the libraries as described in the link above for every project.  This is not an IDE global update, but appears to be a project specific update.

The better approach may be to start the project fresh when moving to 11.x.  I have not done this, so I do not know what fun things this idea can bring. 

 

Android Fun

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.  I spent the last 3 days trying to move one app (TDust) into the play store.  I freely admit that part of it is truly my fault for not keeping the apps up to date.  So trying to move from API 24( Android 7) to the current required API 30 (Android 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, Samsung Galaxy A13.  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 at this point.

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 (Android 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 with specific BLE permissions, which makes more sense.

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, won't be making many trips this summer, so I will have some time on my hands to work on API 31 and 32.

When I went all the way to API 30 and using the very latest Delphi version, 11.1, it all failed big time.  The program crashed, the debugger failed, it was a mess.  I am using the Delphi compiler.  As I have said before, been using this for 30+ years, old dog not going to change now.   So I went back several revisions on the compiler, to version 10.3.3 , used API 24 as the target SDK and the last set of code that worked from my SVN repository.  That worked on all the devices, though the newer Androids 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 Android Apps.  When I got to API 29 (#10) I had to switch the compiler version to 10.4.2.  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 change version of the compiler to 11.0.  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 between 11 and 10.4.2.  This proved useful as API 30 did not come easily.  When I first tried the 11.1 version of Delphi, it would crash on start.  The debugger finally showed that the issue is in one of the units startup code, but I never tracked it down.  I did see in Embarcadero's Developer JIRA a bug report RSP-35804 and RSP-35919.  ( I realize not everyone has access to this, so I will try and describe it.) The first one concerned using location permissions (FINE and COARSE).  The later concerned BLE Discovery which also uses location permissions (FINE or COARSE depending on Android version.  Because the second on was essentially the same as the first one, most info is in the first one.  Embarcadero said it was fixed in 11.1, but people were still reporting the issue.  Basically there was some error in the JNI implementation of location gathering.

But for me, none of this showed up this time in version 11 or version 11.1.  I dont know what happened from the very first time I tried 11.1 and at the end of my slow march through the API levels.  I had other issues with compiler configurations, choosing the correct permissions (COARSE vs FINE) but it never crashed like it did the first time.  All I can say is that 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, LOCATION_BACKGROUND.  I had read an item in Stack Overflow that it was now required, but Google wanted to know why I was using it 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.   So either the StackOverflow and the approved response misinterpreted the Android spec or Android in not following the spec. 

But it cant end here.  I then tested the install on the devices. The older devices were still installing the older version, dont 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.

Year 2022, Where are we headed

 

 

As the New Year dawns, here are the goals for 2022.

Lego Shows to attend

These are the shows we are planning on attending in 2022.  In all cases we will be showing our MOC and a few we will be vending.

Brick Fest Live (San Jose)  March 26 & 27

Brick Days (Omaha)  April 23 & 24

Bricks by the Bay  Jun 23-26

 

Brick Fest Live (San Diego)  Dates TBD

 

Product Development Road Map

Brick Buddy II 

 

 

 

 

 

 

 

 

This really needs to  be done this year and ready for production.  Mostly what is needed to finish is the MP3 section and finalizing the scripting.  This will get added priority this year.

 

Planetary Space Base Expansion

I have some great ideas on how to make this better and bigger. Some of this depends on Brick Buddy II.  I need to continue to build the cliff.  This is largest thing I need to do, but is also the most expensive. 

The two pictures above are renderings of a walker that will roam the cliffs.  I am also working on some construction robots.
 

Train Tools

There are three items here.  These first two are left over from last year.  One I have lots of small displays I acquired years ago.  I want to turn these into billboards for HO train layouts.  They can be loaded with changing displays or a static display.  Also  I have an idea for a battery operated track cleaner.  It would use track power unless the track is too dirty, then it would run on a rechargeable battery. It would also provide real time information back about the track voltage so you could find dead spots via a Bluetooth link and a mobile app.  The final one is to upgrade all of the turnout/signal control units I built 10 years ago and to build a MiWi to Bluetooth interface so I can control the train from a tablet/phone.

 

So we will see if all of this can be done and just how long it will take.

More USB HID Implementation

In this blog post, I discussed the issues I was having with the RAD Studio Delphi compiler and the JEDI VCL implementation of a Windows USB HID Device. Eventually tracing it down to a HID device on one laptop that was causing the issue.  At the conclusion of that debugging exercise, I postulated that there was some issue with the JEDI VCL implementation of the USB HID device that needed improvement.

I spent a few hours today in between other projects attempting to track it down further.   Mostly because it was beginning to bug me.  I dont believe there is an error in the code, it works as designed. What is missing in all of my implementations is the OnDeviceCreateError handler. I have never seen documentation that this is to be implemented, other than a short comment in the read me file that it was included. It is not in any of the examples either.  

After tracing through the code, the absence of this handler was causing the code to fail out completely, since the error is not handled. The code snippet below is what appears to be the minimum required. So far it is working on two projects. Depending on why the device is failing, your implementation may need more error processing than shown here.  

procedure TformXXX.JvHidCtrlDeviceCreateError(Controller:
          TJvHidDeviceController; PnPInfo: TJvHidPnPInfo; var Handled, RetryCreate:Boolean);
begin
     Handled:= TRUE;
     RetryCreate:= FALSE;
     FreeAndNil(PnPInfo);
end; 

My only issue is that in development you will continue to receive the error message that the device cannot be identified, which is what started this. The error message appears when you open the project and close the project. So maybe there is some improvement that can still be done. But for me right now, this has dropped far down on my list of things to do. 

 

 

 

 

 

USB HID Fun for Windows

Almost all the electronics I build rely on a USB HID connection.  USB HID is built into all major operating systems and makes device connection much simpler.  The downside is small transfer size, but my designs rarely move large amounts of data.  While I could probably write an OS driver for other USB implementations, that is time I would rather dedicated to new ideas.  On the Windows side I use RAD Studio (Delphi) to build the Windows Apps.  ( I also use this for the Android Apps).  For the USB HID component I have been using the JEDI project VCL controls, which include a USB HID non-visual control.  Once I determined the correct configuration, this has performed quite well.  It did take a few months to "wring out" all the nuances of the control.

Several months ago I started noticing issues when connecting to the device.  Then apps with USB HID interfaces would not compile. This all began with a new version of the compiler (10.4.x).  I backed up to the previous version and all was great, kind of.  There were still issues on occasion.  (In retrospect, it was only one computer, my HP Elitebook 850 G5, giving me issues on previously compiled apps.)

After too many days of researching this USB issue, I finally found it.  The USB HID component is part of the JEDI VCL library, provided as source.   The source is kept up to date through the JEDI group and has an extensive "ifdef" structure, to ensure backwards compatibility for many versions of RAD Studio.  The USB HID component is compiled when it is installed into the RAD Studio IDE  component palette, this way it is compatible with multiple versions of the compiler.  Sometime after version 10.4.2 of the compiler was released, several patches were released.  Long story short, when the USB HID was installed (without patches), the compilation corrupted the registry access when enumerating the installed HID devices. When I installed the latest version of the compiler on a clean PC, updated all the patches and then installed the USB HID component, it worked just fine, kind of....................

It worked on all the computers, except my HP Elitebook 850 G5 laptop, that is my primary computer.  I kept putting off working on it because it looked like some kind of driver/registry corruption and reinstalling windows and then all the software looked like the only solution.  Well that was not something I wanted to do.  But today it got to be too much, so before trying to reinstall Windows and rebuild the entire computer, I started debugging again. 

What I noticed is that sometimes it would enumerate some HID devices before failing and other times it failed immediately.  So then I started tracking Vendor ID/Product ID data on each device.  After several runs a trend started to appear, it was always the same device failing, but at different points in the enumeration.  Something called "HID Sensor Collection V2".  I disabled the device and then all of the USB HID programs started working.  Looking at my other two computers, neither has this device.  Further digging showed that Windows would allow the generic HID compatible driver to be attached to the device and that also worked.

I have a USB HID exerciser that Microchip use to provide for PIC USB HID development.  It is a small Windows program that gives you all the data on your device in order to verify operation.  It never shows this HID device, unless I use the generic HID driver.  What is happening is that a call to the Windows HID.dll is returning a failure(HidD_GetAttributes), which is verified by the error message the HID exerciser is showing.  Looking into the open source code I am using for the HID interface and tracing to the failure, it is the same call to the HID.dll.  So now I am pretty sure I have found the problem.

So what does this device do?  Dont know for sure, but it looks like it controls several accessories like accelrometer, gyro, temp etc.  The list of devices implies it is for a tablet or tablet mode of a PC.  For now I will use the generic driver and see if anything fails.  The error checking at that point in the code is not robust enough to handle that error and let the program continue to run. On the JEDI forum this problem had been previously noted and I added my data.  A proposed solution is to  ignore the error.  Workable, but not elegant.  Once I get a few more things done, I plan to return to this and see if I cant come up with a solution that will work for more people.

 

Development - LED Control #3

Here is what the PC GUI end up as.  It is a little busy and I may change the theme to distinguish it from the current version.  I like that it will match the Android app.  Except the Android app has separate screens for motor and LED control.  I went with labeling brightness here, to make the Android APP more obvious.  You generally start with the PC first for development, then use the Phone to do actual control.

Still to do some cleanup and then move on to Motor Control.