I don't think that's feasible. Stay with the notion that the Android cannot physically harm your Nano BLE. What has happened will have been a logical alteration.
You can connect your Android phone to other BT equipped devices such as a laptop or PC. You could then send text from the Arduino IDE's serial monitor to your app. That would be via plain BT, not BLE. That could be a suitable way to test your app.
Well, Chris thinks it may have been possible.
OK I have been using the Serial Monitor. But You called it the Android Monitor, Did you mean Arduino Monitor?
I have performed that reset many times since this started.
It's been renamed but you will still see the old name in forum posts.
I still can't force my tiny brain to believe that a software connect/disconnect (or anything) could actually cause physical harm to the board. It could cause corruption, but a reset fixes that. Do you know if these boards are genuine Arduino or copies? The copies are usually very good actually, but maybe the BLE module has not been incorporated well (original or copy). Perhaps an email to the Reseller would bear fruit?
I will give that a try. But it ran using LightBlue without any issues with the serial lines not commented out.
For the moment I have no labels per value, until I learn to use them correctly. But when the problem occurred I had multiple labels as shown below. I guess the question is could code damage BLE?
Thanks for the example. At this time I have very little understanding of this, but I will need to deal with it shortly. The only question is, Can my previous code actually damage the BLE?
That is a later version. I will need to give it a try. I'm using one a few months older. I just installed it 2 days ago, I wonder why I did not get the latest version.
I cant picture it either. All four Nano 33 BLE's I own were purchased directly from the Arduino web sight. I also cant picture me being the first person on the planet to discover a design defect of this sort if there is one.
You have been very helpful, and I have a lot of work to do with the MIT Inventor code. But I cant play with that too much until I get new BLE boards in. None of the things I have done with my Inventor code should have effected the connection with LightBlue, as that never gave me any problems. I can only assume that some way some how, something got damaged. You have uncovered two possibilities, one being the second screen and the other being the multiple labels. So far the only thing I can do is set up some cheep BLE H10 boards to experiment with these before putting in a new Nano 33 BLE. I have 5 H10 boards coming in but that will take a week to get them.
I did come across a more in depth factory reset procedure which I may try.
Not sure I understand. I can successfully open other apps on my Android. Like my irrigation system. I have no idea how to send text to it. but it is communicating.
I believe I have the multiple screen issue under control. Now its time to work with the multiple characteristics. In your example you have 1 ServiceUUID, 1 CharacteristicUUID, and three variables X, Y, Z. In my Arduino sketch I have a service characteristic and 4 Integer Chraracteristic. All my characteristics are 128 bit. This all worked fine with the LightBlue software but I'm not sure how to implement this in the MIT app,
// Define the Temperature Service
BLEService TempService("53436b3f-5f91-474b-963e-8b09b170c670"); //*** BLEService Class Any Hex Name 128-bit UUID in String format *********************************************************
// Define Temperature Level Characteristics as BLEUnsignedIntCharacteristic, BLEUnsignedCharCharacteristic will not work.
// Note define Characteristics and
BLEUnsignedIntCharacteristic RadLevelChar("694d181e-4421-47f3-9653-c4d6bb295a07", // standard 128-bit characteristic UUID *******************************
BLERead | BLENotify); // remote clients will be able to get notifications if this characteristic changes
BLEUnsignedIntCharacteristic CndLevelChar("0407dd37-ae29-4ec7-ab40-a83898d610df", // standard 128-bit characteristic UUID *******************************
BLERead | BLENotify); // remote clients will be able to get notifications if this characteristic changes
BLEUnsignedIntCharacteristic AuxLevelChar("ad43db8f-e3e6-4025-b745-43f2100f27e1", // standard 128-bit characteristic UUID *******************************
BLERead | BLENotify); // remote clients will be able to get notifications if this characteristic changes
This is my app so far:
Not a design defect but a manufacturing defect or transportation damage - given the conditions of manufacturing due to the pandemic, the risks are a bit higher.
Possible Boot Loader corruption. I would give that reset a go just because it's an interesting task in itself.
As you can see in my example, the App accepts a stream (list) of values, you just use an integer value characteristic in the Sketch to write them (essentially the same write code as before but only the one common characteristic).
The phone is running an app called Serial Bluetooth, by Kai Morich. It's a terminal program that sends & receives via the phone's BT.
The laptop is running the Arduino IDE with the monitor open, which is effectively a terminal program. It sends and receives via whatever port has been selected under "Tools".
So the two devices are communicating. What is typed in at the IDE monitor & sent appears on the phone and vice versa. The blue text on the phone was typed on the phone, the green text was typed on the IDE monitor.
So you could test your app by sending messages from the phone (edit: from the IDE monitor, not the phone). But this uses the BT extension not BLE.
When you connect the phone to the laptop, Windows allocates it a COM port. That's the port you set in the IDE.
Might be a warranty issue. The second one only has about 10min of use on it.
I have nothing to loose but it will take me some time to purchase the hardware required.
If I understand you correctly, I only need to change the UUIDs to the same as shown below?
// Note define Characteristics and
BLEUnsignedIntCharacteristic RadLevelChar("694d181e-4421-47f3-9653-c4d6bb295a07", // standard 128-bit characteristic UUID *******************************
BLERead | BLENotify); // remote clients will be able to get notifications if this characteristic changes
BLEUnsignedIntCharacteristic CndLevelChar("694d181e-4421-47f3-9653-c4d6bb295a07"", // standard 128-bit characteristic UUID *******************************
BLERead | BLENotify); // remote clients will be able to get notifications if this characteristic changes
BLEUnsignedIntCharacteristic AuxLevelChar("694d181e-4421-47f3-9653-c4d6bb295a07", // standard 128-bit characteristic UUID *******************************
BLERead | BLENotify); // remote clients will be able to get notifications if this characteristic changes
OK I get that, but don't understand why that will help me determine what is wrong with the BLE function on my board?
No, it won't help you solve that problem. Earlier I think you said you were not able to test your app. So, if you want to develop you're app skills without BLE you could build the app with just the BT extension. Composing a message on the IDE monitor could simulate the output you expect from your instrumentation.
I got, It might be worth tying when I get the new HM-10 boards. Those were 5 for $20. I believe they do both BLE and regular Blue Tooth. If I mess the firs 2 up with BLE, I might try my luck with Blue tooth just so I can develop the rest of the app.
Thanks
@ChrisWard @NissanCedric
Damaged my third Nano 33 BLE. But this time I damaged it using the BlueLight software to read it after changing the code to make all the characteristics the same. In this case I tried my original code first with BlueLight and everything hooked up and went well. Then I changed the characteristics to all be the same as shown below and tired again to connect with the BlueLight. I figured I had no risk with the BlueLight software because it has never let me down until now and in fact it is what I am using in my car at the moment.
So I am coming to the conclusion that miss handling of multiple variables, either in the app that reads them or the Arduino sketch that advertises them can cause this problem. My car works flawlessly with the BlueLight app, but it is very awkward to use.
As far as the HM-10 modules. Those also came in but unfortunately required there own research project to use them. I tried to use a simple demonstration program that I found here and wouldn't work:
Apparently these low cost cloned HM-10 modules need to be flashed to get them to work:
That sound doable but it is a science project on its own.
The other issue I have is that the HM-10 module appears to be sending data differently that the Nano 33 BLE. I don't see any characteristics being sent in the example code. Looks like variables are being passed by a serial communication. I'm not sure how that will translate to the Nano 33 BLE.
I don't know how much time I will have to work on this as I am in the process of moving, but I will do what I can.
// Note define Characteristics and
BLEUnsignedIntCharacteristic RadLevelChar("694d181e-4421-47f3-9653-c4d6bb295a07", // standard 128-bit characteristic UUID *******************************
BLERead | BLENotify); // remote clients will be able to get notifications if this characteristic changes
BLEUnsignedIntCharacteristic CndLevelChar("694d181e-4421-47f3-9653-c4d6bb295a07"", // standard 128-bit characteristic UUID *******************************
BLERead | BLENotify); // remote clients will be able to get notifications if this characteristic changes
BLEUnsignedIntCharacteristic AuxLevelChar("694d181e-4421-47f3-9653-c4d6bb295a07", // standard 128-bit characteristic UUID *******************************
BLERead | BLENotify); // remote clients will be able to get notifications if this characteristic changes
That's because it's possible to use 'Classic' BT methods with BLE devices