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.

Here is a fiber laser machine example: https://mylasermart.com/product/ultra-high-speed-laser-machine/

It uses 50W fiber laser. Minimal track width is 0.05 mm! Space between tracks is 0.025 mm which is limited by the beam size. Precision ±2 µm.

This particular one doesn't look any cheap, but it gives the strong hint what to look for.

@NeverDie Yeah, it's a very interesting option! Similar approach might be to use a UV printer. The UV paint is known to be resistant to FeCl3 and hence results in nice and clean edges. But that's subject of paint and a laser engraver could be used over UV paint too.

On the other hand, a fiber laser might be a nice all-in-one solution. It can do the PCB routing, can cut the board edges, and drill everything in one pass. After that, the same device can be used to manufacture solder mask using a kapton tape and also engrave the silk layer on top of it. Finally, it can cut stencils.

The only missing part is the through hole plating. I still have concern that laser drilled the edges will be good enough for metalization, this has to be checked. But a previously drilled and plated board is much easier to etch with laser rather than a milling machine.

@NeverDie Yeah, this is awesome hack! I'll followup in the CNC thread

Regarding the PCB milling, I found myself thinking fairly often about full-cycle manufacturing too

I usually do small boards, up to 4x4 inch. For this size it should be possible to build an affordable, but highly capable machine. Some thoughts on it:

• High precision. The machine must be able to cut tracks and pads as thin as 6 mils (0.15 mm), but 5 mils would be really nice to achieve. Because of this I'm more inclined to laser cutting. On a milling machine 6 mil gaps between tracks will be hard to do. Another advantage of laser cutting is that it won't tear tiny tracks off the board. Perhaps, even a copper foil can be laser cut. But there's also a spoon of tar: the copper is known to be very reflective and imposes higher requirements to the laser cutter - the price may increase. Another thing to note is that the laser may be not so good at removing large surface areas.

• Kapton tape for solder mask. For sticky mask to apply, I'm also thinking about some kind of a pallet - this would allow to use cheap polyimide tapes from eBay. Alternatively, non-sticky masks can be laminated. Laminated masks will stick stronger and can be two sided - think of it as about three and more layers. Again, laser cutting is preferred here.

• Engraving of the silk layer. Laser could be also used for high-res silk layer over the kapton tape. With laser used, the difference in distances from the head to surface because of the copper layer is not an issue. Engraving on both copper and substrate is also possible.

• Interchangeable heads? Probably, no. The cost of the working head, either laser or milling, will likely dominate over the cost of other components - the machine is small. Seems it's more reasonable to have different machines.

• Assembly machine. This would be my favorite, but first things first.

Hi @NeverDie,

The 39% is a HUGE!

I think there is must some fundamental limit on how much we can get from these oscillations of the, well, Ether. Or is it the quantum vacuum? Or the strings? Well, the very last name to this kind of shit is the time crystals. And, no matter what the name is, the shit can oscillate, and these oscillations are the essence of the energy. So, while currently most of electronic devices employ electrons as drivers, I'm wondering would it be possible to build an electron-less system where the oscillations (aka waves) may be passed through a number of transformations, and this will bring us to some useful things.

Actually, there is RF and optics which works exactly like that. There is also a number of RF harvesters to collect the energy, but the energy is used mostly to push electrons forward, i.e. produce direct current. That's understandable - most of devices are DC. But creating some kind of a microwave transistor would be just rad.

Gah! I've lost the ball

No progress on discrete harvester, sorry. Also, the PV panels I got earlier were shelved until better times.

I still monitor a couple of the SPV1050 devices though. They're running from various PV panels that I switch from time to time. The load is an nRF52833 beacon and sometimes an IMU broadcasting every one second at 0dBm to 8dBm and reporting voltage of attached ML2032 battery to my phone.

My experience is that a tiny PV panel cannot sustain the device working online. By online I mean that both the device and the harvester power consumption exceeds the panel capabilities, so the battery slowly decays. A bigger panel can address the issue. I still unsure how much we will win if a more efficient online harvester like AEM10941 or even more efficient R1800K will be used. A batch harvester is definitely the way to go.

But how about you? Have you had a chance to build anything yet?

@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.