And in less than a week please meet the revision 1.1.

This release addresses annoying NFC bug introduced in rev. 1.0. Such, to cleanup schematic I've moved NFC capacitors to a dedicated space where the C18 was turned upside down in order to improve text readability. This led to C18 net changes which were overlooked for the PCB. After zone refill it resulted in tying the GPIO_P0.10/NFC2 to the ground thus making the whole NFC antenna defunct.

From the good, this revision adds highly requested mounting hole to the main board:

Have a nice time!

@neverdie said in Raybeacon: nRF52 on-the-go Development Kit:

The F-type trace antenna on the esp8266 esp-12F seemed to be the best all-around solution, so I was previously guessing the same would probably be true for the nRF52 as well.

Well, antenna parameters are relevant only to resonant frequency. As long as it matches 2400-2485MHz it should work just fine.

This one on the photo looks like SWRA117 by TI. I used those from KiCad standard library as a simple drop-in solution and they are quite nice.

Then again, the Fanstel BT840X trace antenna seems to be by far the best so far, and it's bigger than the esp-12F antenna:

Yeah, where reduced size is a must, meandered antennas (like the SWRA117 above) are good compromise to straight inverted F-type antennas. Otherwise a straight IFA might show slightly better efficiency.

I'm guessing maybe part of the reason it does so well is because it has less insertion loss than an externally mounted antenna. So, to your earlier point, putting a BT840X inside a cantenna should easily beat externally mounting it to one.

Placing antenna into a can makes to it about the same thing as acoustic guitar body to sound wave - it helps create standing wave and direct it into one particular direction. This simple trick promises to give +10..+15dBi - about the same gain as a power amplifier.

The difference, of course, in radiation pattern. This actually defines the need: do we need long range connectivity in one direction, or it has to be rather omnidirectional? For the first case - use directional antenna, then shape the beam with a can (cheap) or parabolic reflector (affordable), if still low - amplify. Of course, size matters so a small and simple properly placed reflector would make it too. For the latter case just stick to omnidirectional antenna and amplify.

That said, my best experience to date has been with dipole antennas. They're larger still, but they're also very easy to make. Some people have even hacked them onto nRF24L01's and report much better range. I'm guessing that's at least partly because it compensates for the too small ground plane on those devices:

Bigger ground plane usually promises better performance indeed and the module looks very small.

But to be honest, I don't know will the dipole improve anything or not. The nRF24 has balanced antenna feed line so at least it should be possible to connect dipole directly to the module (which is not the case with nRF5). But in order to do this all extra networks must be cut out, and even in this case it's very unlikely the antenna and RF output will match each other. Assuming that both the DIY dipole and the Cypress MIFA are omnidirectional antennas I don't think that the detuned and very likely out of band dipole would beat the original design, sorry.

Luckily, at 2.4ghz the antennas wire length isn't as awkward as it is at sub-ghz. Maybe it could be shrunk down using two squiggle traces instead of just one?

The RF output has 0dBm. Next, the default omnidirectional antenna tries to radiate it with 0dBi gain. Now it's possible either amplify, or shape the beam, or do both. A directional antenna (including reflector as part of it) could help gain up to +20dBi in front (which roughly means you'll have -10dBi in other directions). Amplifier could add +15dBm more in all directions. So it depends.

IMHO the options (inclusive) are as follows:

• Use reflector. Pros: high gain, cheap. Cons: size. Note: results in directed antenna (which may be both good and bad).
• Replace antenna. Pros: better radiation pattern. Cons: needs tuning.
• Install amplifier. Pros: immediate tx/rx gain boost. Cons: extra cost, needs tuning, may drain battery on low-powered solutions.

Hi,

I'm pleased to announce that the first major release of the Raybeacon DK is out. The revision 1.0 offers all the mentioned features and can now be ordered from your favorite PCB service. For highlights please take a look to the OpenHardware description, for details (and sources) please visit the Raybeacon project page.

I've published project BoM on the Octopart where you may easily estimate components. Please note, the aQFN73 package may push you to higher PCB production line. In particular, it suggests ENIG finish and also requires 5 mil track width / clearance, so expect increase in production costs. At the same time I've tried to keep design of the extension slices at the most affordable price so it should be easy to get 10 for $5 and have some DIY fun during Xmas holidays.

The project still work in progress. Such, the radio was tuned for the nRF52840. The nRF52833 may work just fine or may be out of tune. I'm going to order several boards with 833 for that purpose, but it may take a while so please use 833 at your own risk.

And, of course, please don't hesitate to share your feedback, it will be highly appreciated!

Hi @Nca78, I've placed the order on the PCBWay in early January, so it's almost finished. The factory just recently restored assembly services for some kind of boards including this one. Hope to have it in hands within a week or two.

@monte 1) To control all the sensors and 2) to be monitored by the network.

@scalz said in Everything nRF52840:

@NeverDie I think you need to hold it, but it looks there is "coded" holes/slots for helping and correct positioning.

You may want to use TC clip for long-time debugging or odd boards like this:

Thanks!

The board uses aQFN73 package which is kinda two-row BGP with 0.25 balls, so soldering it at home may be quite tricky indeed. I've ordered assembly

The aQFN73 is common package for both nRF52833 and nRF52840. In this particular board you may safely use either nRF52833 or nRF52840 of your choice (need 105ºC and direction finding, or rather more memory and the CryptoCell unit?) The only other thing you have to do is ensure pi network uses correct components for the selected SoC (I'll update the BoM as we can tune it) - the PCB remains the same. Generally speaking, many features are just matter of your BoM. Just do custom assembly by dropping support for USB (C20), NFC (J1, C18, C21), IR LED (or replace it with usual LED), buttons, nRF DCDC, 32KHz crystal, and so on.

On the other hand, if you need an extra stuff for your device (like a MEMS, or microphone, or air quality sensors), you may develop and attach an extension "slice" board. The "slice" supposed to be placed on the back side, i.e. right behind the CR2032 battery. Thus way it will create a kind of sandwich (or probably better said, burger): the Raybeacon board - battery - custom slice board. The red board on the screenshot is an example of such slice developed for my friend. It provides ultralow-power accelerometer, magnetometer, and gyroscope - all in all, we have just CR2032 for that.

@skywatch said in Which vector network analyzer should we buy?:

It will be interesting to see the reviews of the new unit though.....

Big discussion was at https://groups.io/g/nanovna-users/topic/first_pcb_pictures_of_the_v2/68761814. Now it seem continued to the https://groups.io/g/nanovna-users/topic/v2_design/71480430. These topics also explain why some shielding wasn't installed.

Please note, there is also the NanoVNA2 by edy555, but the name has been taken.

@alowhum said in Everything nRF52840:

To what extent Bluetooth has useful smart home profiles
To what extent Arduino devices could present themselves as smart home devices using those profiles.

Well, the BLE has a lot in common with REST. You have to have one or more central devices (clients) which will query peripherals with sensors and actuators (servers). Communication is P2P, but broadcasting is also supported to some extent (various beacons are well known examples).

If thinking about it like a RESTful sevice, there is a number of API which were standardized. They call it profile, like in, for example, the Heart Rate Profile. The standard just assures that any heart rate monitoring device will talk the same protocol as any other one - that's it. I don't think there is many standard profiles for smart home devices (if any). At the same time, there is the Project Connected Home IP.

Of course, there is nothing which may prevent somebody to implement his own interface. If it will be successful enough, it will be later possible to contact the SIG group and promote it to a standard.

Please also note, that for serious boradcasting there is the Mesh. In a nutshell it works similarly to Ethernet switches. Interesting side effect is that it's possible to build a Mesh network physically wide thus delivering packets over long distances. Of course, if you want to go global, the IPv6 will be the right choice to go. It will require a standalone BLE enable router though - it will connect the devices to the Internet.

To what extent older Bluetooth chips can work with newer device profiles (it would seem a software upgrade should be enough?)

As long as they support Bluetooth Low Energy - i.e. version 4.2 or above.

By the way, for hand-soldering version I planning to employ nRF52833 in 5x5 QFN40 package when it will be available. It won't be possible to install anything but 833 there, but the PCB itself should be way more affordable to manufacture and assemble. I think the new board will be 100% compatible with existing "slices" . The current form factor depends on battery size in the first place, and I think it will remain the same. Unsure those 5mm will make big difference if we switch from 2032 to 1632 and loose about 50% of capacity.

@NeverDie Yeah, soldering those tiny packages is sort of PITA. For experimenting with them I thought on a breadboard friendly PCB with the package footprint.

Hi @NeverDie,

I also have the strong feeling that a couple of voltage detectors could make it much easier, yet – due to picoamps leakage – more effective.

Such, in the couple of last days I've tried to reproduce the UB40M circuit with real transistors. Perhaps, when you build a die you can construct every transistor with the parameters you need, but I admit it was not a trivial task to pick anything suitable from a catalogue. I defined no strict constraints to the application, rather tried to be opportunistic and use whatever works. There were some assumptions though:

• Input voltage is defined by the solar cell and is somewhere between 2V and 3V. In the deign below it's set to 2.5V.
• The short circuit current for the cell should not extend 50 nA. I've limited it down to 25 nA with the Rcell = 2.5V/25nA = 100MΩ.
• The harvester should be able to charge 22µF storage capacitor - this capacity should be enough to send a single non-connectable BLE advertisement.

I haven't bothered to find the low leaking MOSFETs and chose something small, handy to solder, cheap, and in stock. That turns out to be power MOSFETs in PowerPAK SC-70 package from Vishay. The nomenclature is SiAxxxDJ where the xxx is what you may see in the circuitry below. For example, 421 stands for SiA421DJ.

The core of the circuit is the pretty much of the UB40M reference design. The series of MP5-MP7/MN6-MN8 triggers will pull Reset line high when VREF will become low. This will happen when MN5 will pull it down, and depends on the Vdet voltage. At the same time, the MP4 will be turned off by VoutL (Reset) thus preventing VinL from being unintentionally pulled to the GND. The MP3 is used as a diode there.

I failed to create the VREF voltage in the way it was defined in the Bristol paper. With the circuit powered by the very low-power source, it suffers from transient processes a lot. To address that, I went for more complicated solution with couple of triggers controlled by Rdet1+Rdet2 divider. The divider also allows to tune the circuit to better match source and storage capacitor.

Finally, there is a 1k load attached to the Vin line. It discharges the Cstore capacitor as soon as the Reset will be set high. Upon discharge, the voltage detector will went reset the Vdet and the Cstore will be charged back.

In my KiCad ngspice it looks as follows. With Vcell=2.5V, Icell=25nA the Vin oscillates between 1.4V and 1.95V. Although this is way below required 1.8V for most of sensors and MCU, raising solar cell voltage to 3.5V will shift the voltages to the usable range.

Discharge current is limited solely by the Rload=1k. At the same time, average current consumption of the harvester is about 3nA - the blue line I(Rharv). Solar cell load is below 10 nA - the yellow line I(Rcell). However, due to non-linear nature it's hard to predict how the line will look like with a real cell. Probably, it's better to simulate it with a current source, I don't know. The red line Vdet shows how the voltage detector works.

To be honest, I'm quite unhappy about the circuit.

First of all, it uses a lot of transistors, please compare this to the BJT harvesters you're working on. Also, many of them work on subthreshold voltages, and this makes it relatively hard to to tune. But worse, real devices will likely to suffer from the voltage interference which makes the whole circuit too fragile. Taking in account the money to build it (even with $0.40 per FET), it turns out the circuit shall be considered rather impractical.

@NeverDie said in The Harvester: ultimate power supply for the Raybeacon DK:

Glad you asked, but it turns out not to be happy news. As it stands, it's a very constant 28.73ua leakage, which is obviously pretty terrible.

The circuit has so low leakage mostly due to the gigohmic resistors. In particular, those 300 pA bumps on AM3 may be due to the R4 limits (3V / 10 gOhm). And it looks like the right thing to do for a BJT. Oppositely, MOSFETs can be used as ultra strong resistors themselves. I.e. should you put several in series and the leakage drops.

I.e. it might be reasonable to drop a MOSFET in the place of T5+T6, and yet another gigohm resistor will cut the T4 leakage down.

@NeverDie said in The Harvester: ultimate power supply for the Raybeacon DK:

Maybe this kind of separation better answers your question about the leakage?

Definitely. Thanks a lot!

It would also be interesting to know measurement from the AM4 when the LED driver circuit is off. You see, MOSFETs are mainly characterized by the subthreshold leakage current between D and S - the AM4 has it.

@NeverDie Congratulations! Looks very holistic. The only model needed is 2SD2704 - cool!

I'm unsure though will it be possible to substitute the star from three 100 pF capacitors with a single one 68pF?

Could you also isolate T4 and T5 from the oscillator, please, so the AM1 won't measure their leakage? It's interesting to compare that cascade to a MOSFET.

@NeverDie said in The Harvester: ultimate power supply for the Raybeacon DK:

Unless you can think of a way to somehow roll-your-own ultra low power supervisor, I'm not aware of anything else. I suspect that maybe the Michigan team that built the Cortex M0 with the ultra tiny solar cell could easily beat both the ABLIC and Vishay supervisors--I'm still gobsmacked by what the Michigan team accomplished-- but at the moment I don't understand how to do the kind of leakage supression that's the foundation of what the Michigan team did. On my one and only attempt, after toying around with it, I was able to get one simulation that seemed to oscillate under very narrow conditions without meaningful leakage, and at first that gave me some hope. However, at the time I didn't see a way to extend that tiny, somewhat dubuious success toward anything useful. Having read the Michigan paper, can you get a leakage supression simulation working, either from their schematic or from one of the other papers? If so, that would be enormously helpful. I could post the simulation that I tried if you wanted to take a stab at it. It's not much, but pretty much anything, even an unremarkable crippled anything, is more than what typically gets published in the academic papers.

IMHO this is the promising direction to go. I haven't analyzed the circuits yet, but the super cut-off idea is dead simple - instead of grounding transistor gates, they have to be under-driven with a negative voltage. This should effectively remove free electrons from the depletion region and hence minimize drain–source leakage. Unfortunately, this requires to maintain an additional negative power source which may draw it's own current to operate. The overhead may be to expensive for a circuit with few gates, but seems well worth it for a processor core with thousands of transistors. What's good, is that this technique clearly separates optimization from the logic. In SPICE it might be easily simulated with a second voltage source, for example, at -0.1V. BTW, for the same reason the higher Vth - the lower DS leakage should be expected.

I'm thinking about building the UB40M alike circuit with any transistors. Well, the FemtoFET series is very small indeed. But size of the biggest package codename F5 is 0.73x1.49 mm which is roughly the same size as 0603 components. With proper PCB footprint soldering them should not be an issue. All in all, what must we expect from a modern high performing transistor?

Unfortunately, my ngspice doesn't work well with the Level 7 model the TI provides. So to have anything tangible to play with I've noticed a complimentary pair from Vishay, Vth=2.5V, Vds=150V: SiA485DJ (P-channel) and SiA446DJ (N-channel). PowerPak SC-70 package also looks appealing - 2x2 mm will help save PCB space, but still not microscopic.

Unfortunately, the P-MOS has no SPICE model, damn it. I'll try to replace it with Si1411DH which parameters looks very close to the SiA485DJ, and there are SPICE models for it.

Some leakage curves for the FETs in the 0...5V range:

Interesting, that the faster raises the voltage - the more leakage occurs. For example, the same chart for 1s raise:

@NeverDie Cool!

A supervisory circuit will be needed between the store and the load anyway. BTW, most of ultra-low power supervisors will consume tens of nanoamps. Does it mean it has to be a low leaking FET?

@NeverDie said in The Harvester: ultimate power supply for the Raybeacon DK:

a couple of interesting things about the NPN ring oscillator are worth mentioning:

It works over a wide voltage range: from 300mv up to 20v.
In contrast to the NFET ring oscillator, where when an NFET is "OFF", it continues to leak current, in the NPN ring oscillator, when the NPN is "OFF", it leaks almost no current at all--maybe just a couple picoamps or less.

Yeah, it is impressive, no doubt. I'm not confident with so low-power circuits and were taught that MOSFETs are leaking less, and BJTs are requiring more current to drive. But this discussion disregards it all, at least when it comes to discretes

@NeverDie Regarding components selection - unfortunately, that's true, too few manufacturers provide that data in a table to compare and select from. So far we have the FemtoFET series from Texas, the FETs listed in the Nexperia's AN90009 paper, and the ALD FETs. General recommendations for a low-lakage FET may be:

• Higher gate–source bias voltage. Obviously, the higher voltage required to turn a FET on - the more resistance between gate and source, and the less leakage.
• Higher source-drain resistance when on. It simply means the FET will have higher resistance when closed too.
• Protection diode may also cause some leakage.

However, an attempt to select low-leakage FETs using these recommendations will certainly fail. It rather seem more depends on specs a manufacturer tries to warrant. For example, in theory high drain-source voltage may imply lower leakage at low voltages. But usually lower power transistors are leaking less.

Such, all Vishay specs I've read for more or less matching transistors mention exactly the same values for GS and DS leakage. Similarly, all ALD transistors have very low leakage because the ALD is working hard to manufacture them so. But I admit, for unknown reason any of those low-leakage FETs are ridiculously small, it's very rare when any dimension is bigger than 1mm.

Looks like if we really want it low, we must accept the size. On the other hand, some youtubers do solder even 008004 which are way smaller.

Alternative way is to choose a couple of transistors and measure them. I think that 1µA leakage from datasheet will barely go over 10nA in practice, so your choice should be just fine.

BTW, SPICE models usually operate with physical dimension, so should be accurate enough when it comes to comparing leakage of different items.

@NeverDie In SPICE the ring oscillator works just fine. I don't see why it may be hard to have it oscillating with any FET. However, due to the fact it's perfectly balanced (at least in it's current form) across all the three transistors it may be somewhat reluctant to start.

Here is how I get it in the light of the power consumption. For convenience, I've re-enumerated all components left to right.

Phase 1. I'm not going to cover the circuit boot and will start at the moment when the Q3 is closed. In the closed state VF3=0 it will tie the Q1 gate and the bottom pole of C1 to the ground. The Q1 is closed, and the C1 will be charging via R1 resistor. The R1 will set the charge time for C1.

At the same time, due to the closed Q3 the voltage source will be grounded via R3 and this results in extra leakage Vin/R3. At this phase, the overall current consumption will be about I ≈ Vin/R2 + Vin/R3

Phase 2. The phase 1 will last until C1 will be charged to the Q2 gate threshold voltage. After that, the Q2 which was previously open due to the C1 voltage drop, closes, and this will tie VF2 to the ground and open the Q3.

The opened Q3 will shift ground level for the C1 thus doubling the VF1 voltage. The C1 will start discharging down to zero until VF1 won't balance VF3. Actually, the C1 it will be charged from the opposite side via R3. The R3 defines period of the stage 2. Consumption current should be about the same I ≈ Vin/R2 + Vin/R3. Please note, since the Q2 is not participating in C1 charge/discharge it should be safe to keep R2 resistance much higher than R1 and R2, like 300g or so, and decrease the circuit consumption.

However, it seems slightly more complicated than that. Due to FETs non-linearity, at marginal gate voltages there is some drain–source resistance. Despite the Q1 is open with VF3 voltage, it's not enough to have the C1 grounded, and this is why the circuit works at all. Instead, both C1 and the voltage source will be leaking via the Q1. While voltage source is limited by R2, the leakage for C1 may be quite high and require extra attention. Luckily, this is not true for the SiSA40DN - the C1 slowly discharges via Q1 and this compensates for leakage from the voltage source via R1.

Repeat. Upon C1 discharge it's going to close Q2 and raise gate voltage on Q3. The Q3 opens, VF3 voltage drops, then Q1 closes too, and the C1 starts charging back again.

Well, as for an astable oscillator the circuit looks cool, definitely would be interesting to build. But for energy harvesting purposes I'd prefer some UB40M variation - IMHO it's much cleaner from the point of parasitic leakages. Especially if taking in account those leakage optimization techniques like we've seen for the super cutoff gates.