nRF5 action!

[Nca78]

@NeverDie said in nRF5 Bluetooth action!:

In fact, both the Fanstel BT832 and the BT832X (with no LNA turned on) have much better receive range than an Ebyte module. They are head and shoulders better. In turn the BT832X (again, even with no LNA turned on) has a noticeably better receive range than the BT832.

So, at this point, I'm sold on the Fanstel modules for the most common uses. The Fanstel modules also have a smaller footprint than the Ebyte modules. The Ebyte modules might be better for those cases where you need a lot of easily accessible pins to do something, but that's about it I think.

Now we need to convince Fanstel to find another shipping method outside the US :D

[Toyman]

@NeverDie it looks like we found an ideal gateway.
What about the code they provide to activate PA+LNA?
Can it be used in mysensors?

[NeverDie]

I tried out the sub-dime sized BC832 on a quick port of the BC832X breakout board:

What I'm finding is that the Rx range for the BC832 is about the same as for the Ebyte nRF52832 module: I'm hard pressed to tell which is better than the other. The BC832 is nonetheless impressive, given how small its antenna is relative to the Ebyte antenna.

[NeverDie]

@Toyman said in nRF5 Bluetooth action!:

it looks like we found an ideal gateway.

Agreed. :)

@Toyman said in nRF5 Bluetooth action!:

What about the code they provide to activate PA+LNA?

I only extracted the needed info from their code to make it work. It works just fine with mysensors. For instance, here's mysensors code to activate the PA:

#define PA_PIN 17
#define CPS_PIN 6
#define LNA_PIN 19 

  myNrf5_pinMode(CPS_PIN,OUTPUT_H0H1);
  digitalWrite(CPS_PIN,HIGH);  //disable.  Active LOW
  //while (!(digitalRead(CPS_PIN)==HIGH)) {} //wait until confirmed
   
  myNrf5_pinMode(LNA_PIN,OUTPUT_H0H1);
  digitalWrite(PA_PIN,LOW);  //disable.  active HIGH
  //while (!(digitalRead(LNA_PIN)==LOW)) {} //wait until confirmed
  
  myNrf5_pinMode(PA_PIN,OUTPUT_H0H1);  
  digitalWrite(PA_PIN,HIGH);  //enable.  active HIGH
  //while (!(digitalRead(PA_PIN)==HIGH)) {} //wait until confirmed

  //myNrf5_pinMode(CPS_PIN,OUTPUT_H0H1);  
  digitalWrite(CPS_PIN,LOW);  //enable.  active LOW
  //while (!(digitalRead(CPS_PIN)==LOW)) {} //wait until confirmed

I've tested it, and it works. From my testing it appears that the pins are write-only (which is why the while loops are now commented out).

[Jokgi]

@Nca78 How about sending a email to the company and ask if there is a distributor / Rep in your area?
Dr. Yuan Fan
Fanstel Corp.
Trusted Name Since 1990
7466 E. Monte Cristo Ave., Scottsdale AZ 85260 USA
Tel. 1480-948-4928 x101;
email: yfan@fanstel.com http://www.fanstel.com

[NeverDie]

@Toyman said in nRF5 Bluetooth action!:

it looks like we found an ideal gateway.

Yup, here's my gateway:
https://www.openhardware.io/view/491/PA-LNA-nRF52832-ESP-LINK-Shield-for-Wemos-D1-Mini-ESP8266

[NeverDie]

@Toyman Have you received your Fanstels yet? I'd like to compare notes with someone on the LNA part of it.

[Toyman]

@NeverDie I haven't ordered yet. Waiting for my paycheck.

[NeverDie]

When you combine my BT832XE gateway with the LNA on this external "booster," the result is really great reception range, even at 2Mbps:

I think this combo will be hard to beat. In fact, I can receive even from nRF24L01's that are far away (further away than a nRF24L01 with PA+LNA can receive). :)

[rmtucker]

Well my NRF51822 has been running 25days approx sending every 60secs on a cr2032.
No signs of problems yet.

[NeverDie]

@rmtucker I don't recall whether you already have, but would you mind posting a photo of your node?

[rmtucker]

@NeverDie
Its just the waveshare ble400 board but i have cut one of the tracks to prevent the residual drain from the on board regulator.
And i have an external cr2032 battery holder feeding it.
I would love to make a small pcb for the NRF core to plug in to instead of the big motherboard as below, but i failed dismally at the design side of things.

[NeverDie]

@rmtucker said in nRF5 Bluetooth action!:

I would love to make a small pcb for the NRF core to plug in to instead of the big motherboard as below

Here you go: https://www.openhardware.io/view/510/Button-cell-Temperature-Humidity-sensor#tabs-bom

This should be even smaller and less expensive than what you wished for. I made it for the Si7021 because I had some extras laying around. The BME280 would also be a good choice.

[rmtucker]

@NeverDie
That would be perfect but i would have to order everything from china.
Well maybe not the led and resistor.
I also prefer the si7021 also it has far less consumption and quite accurate.

[NeverDie]

@rmtucker said in nRF5 Bluetooth action!:

I also prefer the si7021 also it has far less consumption and quite accurate

As long as the humidity is less than 80%. Otherwise, you need to turn on its "heater" to avoid permanently ruining its humidity accuracy.

[Nca78]

@NeverDie it's not that quick, it happened only to the one I put in bathroom with very high humidity for a long time.
Other sensors reached over 90% humidity sometimes and spent many days in the 75-85 range but just a nightly use of aircon seems to have maintained their hability to measure humidity.
So my feeling is unless you are in a very humid environment you should have no problem with the si7021.

I'm in a tropical country and problem happened during rainy season, >80% humidity at 30°C makes a lot of humity in the air, I don't think you get close to that level in European countries or most of the US.

[NeverDie]

@Nca78 I'm just taking what the datasheet says at face value. In practical terms, I think it's fairly rare to see >80% humidity in an indoor "conditioned space" (well, maybe a bathroom is an exception to that sweeping generality) but outdoors it happens by definition anytime the air temperature approaches the dew point. That certainly does occur in quite a lot of geographies.

So, for that reason, I think of the si7021 as more of an indoor TH sensor. From what I can tell, the BME280 doesn't have this issue, so it would therefore seem to be a good choice for outdoors.

Of course, the si7021 sensor modules are made in Asia, and if it's tropical asia (Thailand for instance?), it may have already been exposed to high humidity. So, that's a bit of an unknown factor hanging in the background.

Anyhow, thanks for the additional insight that maybe the si7021 really needs to soak in high humidity for a long time before it gets ruined. Otherwise, it can spring back from brief exposures. I certainly hope that's the case. Running its heater does consume a significant amount of current.

[NeverDie]

It turns out that on the nRF52832, pins 9 and 10 are assigned to NFC by default. The following code allows them to behave "almost" like regular GPIO pins:

  //Make pins 9 and 10 usable as GPIO pins.
  NRF_NFCT->TASKS_DISABLE=1;  //disable NFC
  NRF_NVMC->CONFIG=1;  // Write enable the UICR
  NRF_UICR->NFCPINS=0; //Make pins 9 and 10 usable as GPIO pins.
  NRF_NVMC->CONFIG=0;  // Put the UICR back into read-only mode.

Well, good enough for a blink demo anyway.

[NeverDie]

Is there some particular trick to reading the built-in temperature sensor? I've tried it a number of ways, but after doing

NRF_TEMP->TASKS_START

I can never get NRF_TEMP->DATARDY to return true, no matter how long I wait. If I just try reading NRF_TEMP->TEMP anyway, it always returns zero.

[Edit: Nevermind. The answer was right in front of me. It obviously should have been:

NRF_TEMP->TASKS_START=1;

Because the PPI uses the former syntax, and the regular code uses the later syntax for the same thing, I sometimes interchange the syntax by mistake.

Anyhow, problem solved. :)

[Uhrheber]

@NeverDie said in nRF5 Bluetooth action!:

BT832XE

What booster is it?