Further, even if the source values are known before hand, you still need to signal the DUTs somehow to compute and 'lock-in' the calibration coefficients for each calibration point. Bluetooth broadcasting is an excellent way to do this if you happen to have a radio installed anyway -- after which it just becomes code, which is free!

 

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.

1/2 of your inferences are correct!

Congratulations with the successful project!

Thanks. It is pretty impressive, IIDSSMS.

 

I placed my "Instant Wireless Calibration" into service in production today. What was a 30 to 60 second operation on each instrument is now an instantaneous operation for any number of instruments.

I got a ooooh's and ahhhh's from my production personnel, followed by a standing ovation -- seriously.

 

Here is what the final project looks like, printed out on 8.5" x 11" paper in 6 point Courier New font:

 

Here is what the final project looks like, printed out on 8.5" x 11" paper in 6 point Courier New font:

View attachment 109616

6 point?! ... No wonder you're so proud of your work ... congrats!

So ... Chick-Fil-A ... uh?

 

So ... Chick-Fil-A ... uh?

Yeah. That's my, ummm, day job.

 

Yeah. That's my, ummm, day job.

As Seinfeld would say: Not that there's anything wrong with that!

 

As Seinfeld would say: Not that there's anything wrong with that! View attachment 109617

Hey, don't knock it. Free food and all, you know.

 

Why have you printed it?

 

Why have you printed it?

I keep a hardcopy plus numerous backups of all my work. The hardcopy is the ultimate, final resource in case all the others fail.

Something I read in a Tom Clancy novel long ago, Executive Orders, stuck with me: "If you don't write it down, it never happened."

 

I keep a hardcopy plus numerous backups of all my work. The hardcopy is the ultimate, final resource in case all the others fail.

Something I read in a Tom Clancy novel long ago, Executive Orders, stuck with me: "If you don't write it down, it never happened."

In that case maybe you should have that hard copy bind with hard covers and all

 

In that case maybe you should have that hard copy bind with hard covers and all

How much do you charge?

 

How much do you charge?

For you? Nothing... if you actually let me see all the code and what it does...

 

For you? Nothing... if you actually let me see all the code and what it does...

Fine. But it has to be leather bound, and look like this:

 

Fine. But it has to be leather bound, and look like this:

You lack ambition, my friend... the borders of its pages should be gilded, and its artwork comparable to The Book of Kells...
It's also a great animated movie, btw

 

Cheers for posting all that, I have been reading up now we have moved in! I know the post is a bit old now, but it looks much more complicated than I hoped... ? All I want to do is fire a few bytes at a android.
Should I stick to the rn42 that I got to work easily or have a stab at the 4020? It is much cheaper !
Cheers Geoff

 

Cheers for posting all that, I have been reading up now we have moved in! I know the post is a bit old now, but it looks much more complicated than I hoped... ? All I want to do is fire a few bytes at a android.
Should I stick to the rn42 that I got to work easily or have a stab at the 4020? It is much cheaper !
Cheers Geoff

It's complicated because it's robust. If you're just one-up playing around, it can be done far more simply.

 

It's complicated because it's robust. If you're just one-up playing around, it can be done far more simply.

Thanks, I just want to give the thing a name and send out blocks of 8 bytes and I don't need to do anything else while its happening (thank goodness!) I'm sure I will be referring to this thread while I sort it.
Cheers Geoff

 

I am writing the following for those not too versed in BLE, and also for me to read over and over again until it becomes muscle memory (the operative muscle being my brain, of course).

1. If a value is written to a characteristic, and neither the notify or indicate property is set or enabled, the value is only written locally, and no transmission occurs to central (i.e. central must manually request the value, if it wants it).
2. If a value is written to a characteristic, and the notify or indicate bit is set but not enabled, same as #1.
3. If a value is written to a characteristic, and the notify or indicate bit is both set and enabled, a transmission of the value is sent to central and a notification is also sent to indicate to central that a new value has been received.
4. If a value is written to a characteristic, and the indicate bit is set and enabled, #3 occurs, followed by a return acknowledgement sent from central.

Specific to the RN4020, for each case:

1. An AOK is returned to indicate the value has been written locally.
2. Same as #1.
3. An AOK is returned to indicate the value has been transmitted followed by another AOK to indicate the notification/indication has been sent.
4. Same as #3, but the second AOK is not returned until the acknowledgement has been received.

This is very badly, and insufficiently, documented in the RN4020 guide.

 

Thanks very much for this extremely informative thread. I have just been asked to debug a RN4020 based device and was pulling my hair out. The documentation really is dreadful. Reading this has clarified the status enormously. Very well done.