The more you suffer the better it feels when it's done

You can also reverse the value on the Android side if you wish.

 

The more you suffer the better it feels when it's done

You can also reverse the value on the Android side if you wish.

It would still feel pretty good without the suffering.

 

Here are the final numbers for my project:

The program memory, without Bluetooth installed, is 16354 bytes (8177 words)

The program memory, with Bluetooth installed, is 20,580 bytes (10,290 words).

Therefore, my Bluetooth code, including strings and the code to interface with the main app, takes 4,226 bytes or 2,113 program words.

Not bad.

 

Somewhat related Joey, MCP recommends to make available the 4 specific pins used in the factory for tests in case the module has to be checked. It seems that an approval could be needed requiring a such a test.

I was reading back over this thread, and this post from last November popped out at me.

@atferrari, do you have an appropriate link you can refer me to?

 

I was reading back over this thread, and this post from last November popped out at me.

@atferrari, do you have an appropriate link you can refer me to?

Sorry Joey, it was a mistake. I confused the RN42 (I was starting to deal with it at the moment) with your RN4020.

I edited my post to keep the whole thing straight.

Excuse me.

 

I am not as dumb as I thought.

Back in post #106, I detailed the problem I was seemingly having with bandwidth. I assumed that I was trying to send data faster than was possible, so I added the indications to slow things down. But, in the back of my mind, I knew I was not sending so much data as to swamp the connection. Adding indications did ensure that data was not transmitted faster than the radio connection could handle, and eliminated the errors I was getting, so that had to be the cause of the problem, right?

Wrong. And, no, there was not a bug in my code.

The RN4020 has a problem. And it has to do with the BLE standard battery service. It seems that if the first private characteristic I add has the notify/indicate bit set, any write to that characteristic causes 1) data corruption of the value of the battery service and 2) a stream of battery service notifications to central, thus swamping the connection.

This problem is eliminated if the first private characteristic does not have the notify/indicate bit set.

As a second clue there is something wrong with the RN4020 battery service, I should be able eliminate the service entirely through the SS command. When I do this, the battery service still shows up as available on the Android. This should not be the case.

I cannot believe how many hours I wasted because of this bug.

FYI: The RN4020 I have is firmware version 1.10. The latest is 1.23 (which I'll be using for production), but I don't have one. This may have been fixed, but I've seen no errata on 1.10 that mentions this as a problem.

I've finally had a chance to try out the 1.23 firmware. Yes, it fixes the above problem.

But...I spent a day trying to figure out why the 1.23 would not work with the same code as the 1.10.

It turns out that the 1.23 firmware is much faster than the 1.10, and it was filling my 256 byte buffer faster than I could process the data during the LS command. I solved that problem by expanding the EUSART receive buffer to 512 bytes.

I consider this a substantial waste of RAM in order to process one single command. There should be an option to be able to request one line of data at a time, rather than having to dump and receive the data all at once.

 

It turns out that the 1.23 firmware is much faster than the 1.10,

That says something about the quality of the firmware's code of version 1.10

 

That says something about the quality of the firmware's code of version 1.10

Yes. 1.10 is riddled with bugs and was replaced sometime back. I started with it because that's what I had. In fact, there is a 1.33 that I am going to production with.

 

Yes. 1.10 is riddled with bugs and was replaced sometime back. I started with it because that's what I had. In fact, there is a 1.33 that I am going to production with.

It also tells me something about the enormous pressure there must've been on the developers to rush the product into the market.

 

It also tells me something about the enormous pressure there must've been on the developers to rush the product into the market.

Yes. Going through the Microchip forums, it has been a bit of a fiasco.

 

My customer has been testing the first beta unit. He is thrilled.

His words: "Best product I will ever have sold."

 

My customer has been testing the first beta unit. He is thrilled.

His words: "Best product I will ever have sold."

Congratulations!

You have good customers

 

And BTW, may I suggest an excellent alternative to Guinness next time you celebrate? :

​

 

And BTW, may I suggest an excellent alternative to Guinness next time you celebrate? :

View attachment 108243​

Nope. Scotland voted remain. I must punish them by boycotting their beer...

 

I made a new 'discovery' yesterday, and it is nothing less than earth shaking for me.

Keep in mind until a few weeks ago, I knew absolutely nothing about BLE. Now, I am learning more every day, and it is fascinating.

Did you know that BLE has a broadcast mode? Technically speaking, BLE broadcasting is sending an "undirected" "unconnectable" advertisement, which can be received by "observers". The advertisement can contain up to 25 bytes of data.

Why is this neat? Because it allows one BLE device to communicate (small amounts of) data to potentially hundreds of other devices within about a 100m radius -- all at the same time.

Me? I think this is pretty awesome, and something I think I can find lots of use for.

FYI, the RN4020 supports both broadcaster and observer roles -- and with some code, simultaneously.

Edit: and by "simultaneously" I mean the radio can be switched, on the fly, between broadcaster and observer roles.

 

Here's an article I found that explains further:

http://www.eetimes.com/document.asp?doc_id=1280724

 

I made a new 'discovery' yesterday, and it is nothing less than earth shaking for me.

Keep in mind until a few weeks ago, I knew absolutely nothing about BLE. Now, I am learning more every day, and it is fascinating.

Did you know that BLE has a broadcast mode? Technically speaking, BLE broadcasting is sending an "undirected" "unconnectable" advertisement, which can be received by "observers". The advertisement can contain up to 25 bytes of data.

Why is this neat? Because it allows one BLE device to communicate (small amounts of) data to potentially hundreds of other devices within about a 100m radius -- all at the same time.

Me? I think this is pretty awesome, and something I think I can find lots of use for.

FYI, the RN4020 supports both broadcaster and observer roles -- and with some code, simultaneously.

Edit: and by "simultaneously" I mean the radio can be switched, on the fly, between broadcaster and observer roles.

I "invented" a use for this over the past few days:

Imagine you are the manufacturer of instruments that measure some electrical quantity. Each instrument has a digital calibration (I stopped using mechanical pots eons ago for calibration -- all calibration is done with code and math now) and each must be calibrated against 2 or more known values.

Traditionally, one would power up the instrument, attach it to a known source, and press some buttons to activate some code to (digitally) adjust the output to the proper reading. This would be done at multiple data points, and for each instrument during the manufacturing process.

So, if you manufacture 1000 units per day, this must be done 1000 times.

The instruments in question now each have an RN4020 installed which supports both broadcasting and observing modes. I added some code so that any unit can become a broadcaster or observer as part of the manufacturing test process.

All I need to do is hook any number of units up to the known source, calibrate one (!) of them, and tell it to broadcast the desired output to the rest, and they all calibrate themselves automatically, simultaneously, and instantly.

This works for 10, 100, 10,000 or more units, as long as they are within 100 meters of the broadcasting unit and tied to the same source.

Talk about a productivity increase! I'm enjoying this!

 

Sounds very interesting.

However, I don't quite understand. If you connect a unit to a known source, the source (since it is known) can tell the unit what it is connected to, so the unit has all the information to calibrate itself. By multiplexing the calibrating sources, you can completely automate the calibration within the test site. Since the test site already has all the information that is needed for the calibration, why does it need to connect to other test sites?

 

Sounds very interesting.

However, I don't quite understand. If you connect a unit to a known source, the source (since it is known) can tell the unit what it is connected to, so the unit has all the information to calibrate itself. By multiplexing the calibrating sources, you can completely automate the calibration within the test site. Since the test site already has all the information that is needed for the calibration, why does it need to connect to other test sites?

In this particular case, the instruments are connected to a source, the value of which is known only through measurement via a (off-the-shelf) reference instrument. IOW, calibration is not necessary performed at the same reference point(s) each time -- those points can vary, but are known via the reference.

Therefore, the first (broadcaster) unit is set to the value indicated by the reference, and all the rest (observers) follow.

Now, you may ask: why not just always calibrate at the same reference point(s)? Often this is possible. For some types of measurements (in this case, for instance) it is impossible.

 

I see. I would infer that the source is not something electrical and is not capable of telling its values to the chips being calibrated. At the same time it is incredibly big, so that its characteristics are the same for the chips 100 meters away from each other. I can't guess what it is, but it sounds fantastic Congratulations with the successful project!