DS18B20 with Bluz_DK (web ide)


#1

@eric, I tried adding DS18B20 library and I am getting Platform ID not supported by this library compile error.

Could you please let me know how to add the library or is there a Bluz version? I need to add two temp sensors to Bluz DK. thanks.


#2

This would require some merging from this repo: https://github.com/LukeUSMC/ds18b20-bluz to this repo: https://github.com/LukeUSMC/ds18b20-photon

The biggest change is in the file firmware/Particle-OneWire.h. This would be pretty trivial to merge, just take the code for platform 103 (bluz) from the bluz repo and merge it into the Photon repo.

The biggest issue is changes to the example.ino script. There are two issues here. First, this example uses Serial instead of Serial1. This could be modified pretty easily, however.

The other is that the bluz needs to use the radioCallbackHandler to only get the temperature when the radio is off, otherwise the OneWire timing gets messed up. Again, this isn’t terribly complicated, just requires some blocks like this:

#if PLATFORM_ID == 103 // bluz
    // do some bluzy stuff
#endif // end bluz

I know @Fragma had some success getting this working, and of course the library author is @LukeUSMC so I am pinging both of them. Perhaps we can coordinate getting these changes merged in, or you can try for the PR to the repo if you would like.


#3

Luke’s code works as-is but it does the CRC check and retry in the main application code. I enabled an alternate way that does this in the library. Just need to find the right code. I got side tracked on trying to fit within the radio off times back when I was finalizing it. Using the radio callback to do this only offered a small increase in success rate and wasn’t worth passing this information to the library. If getting the temp the first try is very important then turning off the radio was 100% successful. Otherwise if I remember correctly my code had to try roughly 1.8 times on average and returned successful 99.8% of the time. I also implemented variable timing which can save significant time if not needing 12bit resolution. All of this dropped the average time to a successful 9bit read from 1.5sec to 140ms.

Give me a day or two to find the code and make sure it still works :wink:


#4

that sounds amazing. I am interested in your code as well.
question: have you measured by any chance how much time does a bluz DK last on a CR2032 battery with your changes?
thanks,
Gustavo.


#5

You can get my code here:


I’ll send a pull request to Luke later today.

I tested it over the night and it got the temp successfully 100% of the time over 20k attempts. There is a fair amount of debug code in the example which you can remove but I found helpful for testing. Obviously disable the LED blink if using with a battery. I haven’t done a battery test yet, I was waiting for Eric to add the configurable BLE connection interval. Plus I haven’t decided if I want to leave the BLE connection enabled and allow my other devices to poll this one for temperature or if I’ll keep the radio off most of the time and periodically enable it to report the temp to my other devices. Most likely I’ll only push/pull temp every 5-10min.

There are 3 known issues with this library:

  1. It typically takes several attempts to successfully find the sensor. It only needs to do this once. I thought it may be time based but a large delay before the first attempt didn’t help. I thought it may be due to the BLE radio but retrying 5x immediately didn’t really help. I didn’t put too much time into solving this but it is the primary reason Luke’s code had a high failure rate as it was redoing this search before every read.
  2. Resolution seems to have no impact; it was like this before I made any changes. I did a test where I’d get the temp with all 4 precision settings and they all return the exact same value; in other libraries I see differences, ie 74.10 vs 74.37.
  3. You can only read from one sensor. Other libraries separate the address finding and reading making it easy to discover all sensors and then read from them all.

If I get time I’d like to make the Bluz changes to the other more complicated library (SPARK-DALLAS-TEMPERATURE) which I use for my Particle devices so I can maintain code compatibility.


#6

Awesome, thanks!

One note, the connection interval changes are now available. This is a gateway setting, but it does require v2.0.50-beta to work. You also need to update your gateway to the latest code here: http://staging-console.bluz.io/

Once you do that, there is a Particle function for the gateway called setConParam, you can access it via the CLI or Particle App. You need to hand it two numbers in the format “X,Y” where X is the minimum allowable connection interval and Y is the maximum. Range is 20 - 300, and those are in milliseconds.

So to get the highest connection interval range, you can do this from the CLI:

particle call [device id] setConParam “250,300”

That will set the connection interval to 250mSec to 300mSec, which is a 10x increase from the default. This should give a boost to battery performance as the radio is now turning on 10x less often. It will, of course, also decrease throughput, which you probably won’t notice for Particle cloud features with the exception of OTA updates, which will be slower.

The data doesn’t persist between power cycles, so if you turn the gateway off/on, you need to call the function again. We are most likely going to change this so it will persist.

We are also going to add a nice way to configure this from the console website, just haven’t gotten there yet, but you can call the underlying function on the gateway for now.


#7

Great, must have missed that, though I had assumed it would be a BluzDK level setting done in code. What was the default setting; 25,30? So the only downside would be at most an extra 225-270ms delay in fulfilling cloud requests? Would that also apply to DK initiated requests like a Publish? Is throughput the correct term or latency? Reduced throughput to me sounds like some operations after the initial delay/latency would also be slowed down, perhaps because they couldn’t do everything during the allowed connection interval. I was thinking if there was incoming/outgoing data that it kept the connection open until the everything was done but perhaps I’m mistaken.


#8

you rock, thank you.
Gustavo.


#9

The default connection interval before was 20-30mSec, so it is actually a bit more than a 10x savings.

Any data may have to wait up to the connection interval to go to/from bluz. BLE works by the two radios syncing at a connection interval and sending packets if need be, which can be a max of 20 bytes. BLE allows 7 of these packets to be sent in one connection interval, no matter the length of the interval, and so throughput will certainly be affected. The hardware gateways actually allow only one packet per connection interval, so throughout can drop dramatically when the connection interval is lengthened.

In between connection intervals, after the packets are sent, the radios are silent and no data can be transferred.

We will move the setting to code before we GA, we just wanted to get it out there for now, hence the Particle function. This isn’t documented yet, so that is probably why you hadn’t seen it. We will get more details about it out there shortly.


#10

@eric, thanks. I am able to run Luke’s example from github.