Author here -- thanks for the comments and feedback! I typically use the solder stripping technique as well when actually incorporating the inductor into a circuit. Interesting you should mention variable capacitors as I just went through the process of sourcing 5 of them (will be discussed in a future post) from Amazon, and not only were they expensive, but they also took significantly longer to ship than was originally estimated.
I am somewhat surprised that the small loops would pick up a meaningful amount of noise, though I suppose meaningful always depends on the use case and tolerances. Do you have any references for how significantly this can impact inductor performance? Or is the primary concern just the rubbing and potential shorts?
Despite ferrite core inductors and loopstick antennas being old, fairly well understood technology, I have found there to be very little in the way of hands-on experiments with tangible results available. I'm hoping to continue testing various techniques and posting about them -- you've already provided some great variations for me to test out!
> Interesting you should mention variable capacitors as I just went through the process of sourcing 5 of them (will be discussed in a future post) from Amazon, and not only were they expensive, but they also took significantly longer to ship than was originally estimated.
It really took me by surprise, I was ready to buy a bag of them and then I realized that the price was for single pieces! And those were the crappy foil kind, not even the cermic/silver versions which seem to be unobtanium.
> I am somewhat surprised that the small loops would pick up a meaningful amount of noise, though I suppose meaningful always depends on the use case and tolerances.
So was I :) But the spectrum is extremely polluted on the low end, just about everything contains a switching inverter these days and they're not exactly clean so you have to pay extra attention to this on the receiving end. Higher Q helps (more coil, less C), up to a point. Above 500 KHz or so it cleans up a bit but below that it is a real problem, because it is not just the fundamentals but also the harmonics which for a switched coil go up very high (in theory: to infinity, in practice, easily to 10x the switching frequency before they fall off to the point that you can ignore them).
> Do you have any references for how significantly this can impact inductor performance?
For me it made the difference between having something working and not being able to recover the signal at all. In the end I chose an extremely high impedance pre-amp and a coil/cap combination that is on the edge of what you can still make at home without having to worry about stray capacitance. It helps that I know exactly what the pattern of the signal is that I'm looking for as well, so maybe if you end up having problems you can use that kind of trick to raise your signal above the noise floor.
> Or is the primary concern just the rubbing and potential shorts?
That's the secondary concern. Also: beware of using metal in your fixtures and metal objects near to the receiver, that can have a massive effect (imaging, signal attenuation, or, if you're really lucky, signal amplification). The potential shorts issues usually only show up over the longer term, you can compensate for quite a bit of that by mechanically fixing your windings using either glue or by dipping the whole works into inductor resin and letting it dry.
> Despite ferrite core inductors and loopstick antennas being old, fairly well understood technology, I have found there to be very little in the way of hands-on experiments with tangible results available.
True, that's because these are the ways of the past, the modern way is to get out of the analog domain as fast as you can and then to do the rest digitally.
> I'm hoping to continue testing various techniques and posting about them -- you've already provided some great variations for me to test out!
Enjoy this, it is very rewarding to pick signals out of the air and there are a lot of interesting lessons to be learned by doing this the 'hard way'. Feel free to mail me if you want to take this off-line, email in profile.
If you can afford losing a bit of frequency stability, you can use a varicap instead and control it by voltage. Precise multiturn potentiometers are much cheaper. Or just buy a programmable clock signal generator based on PLL and then make it into a superhet (you can still have analog filtering and detection, but digital frequency synthesis so it can look more like a modern radio with frequency display).
There are so many options and all are very cool to explore.
Yes, varicaps are good and there are even varicaps with very large capacitance swings exactly for this purpose.
But it does require a very steady voltage and many more parts than just a single passive to not accidentally load the resonant circuit to the point that it becomes ineffective. You need to de-couple considerably to make this work, especially without injecting (phase) noise. And frequency stability and phase noise can be extremely annoying in particular applications.
That’s why you probably want to use it in an oscillator rather than a filter. Then some of those problems go away. Although, some new ones appear like having to add a mixer …
Some time ago I thought making a double superhet would be too complex but apparently it turned out quite a nice DYI project.
One of the problems I'm struggling with is that I'm trying to recover a signal with a known pattern from under the noise floor and every little bit helps. Varicaps will come into play once there is enough signal that the thermal noise and power supply influence would no longer drown out the signal. Interesting project but it is one of those where when you start you think 'how hard could this be?' only to find out that it is in fact pretty hard. We'll see if I can pull this off or not, I give it 10% chance at the moment.
Oh, and superhet wouldn't work, that would destroy the valuable part of the signal.
What do you mean it would destroy the valuable part of the signal?
If the signal has a carrier (like in AM or FM) or some other regular pattern (e.g. digital signal) then the typical the way to recover it from under the noise floor is to use a narrow-band PLL.
I’m experimenting with it right now and just found that a quartz/ceramic oscillator pulled by a varicap controlled by a PLL gives pretty good results - low phase noise, good noise rejection and ability to recover the carrier from a very noisy signal. But for that to work, the signal has to be shifted to a constant frequency through heterodyning first.
The exact phase of the input is what I'm after. Using a LO would cause you to read the mixture of the LO and the input signal rather than just the input signal, and that means that you will never see the phase with the same precision as if you were to observe it directly because the two will have slightly different frequencies.
If you were to put both on a scope in XY mode you'd see the phase change directly over time.
But I like your two step approach, use the het to get close and then lock on to the phase.
So far I've not been successful without first bringing the signal up to the point where I can do it directly and then I don't need to add the complication of a PLL.
Injecting various levels of noise into the signal is a good test to see if the system would still work in less than ideal conditions and so far the answer is a hard 'no', it may well be that I'm past my level of competence on this but it's only been a couple of weeks so I will keep trying.
One possible approach is just to use a flash AD and move the whole thing into the digital domain. That has a bunch of other advantages as well, the signal is not particularly high frequency so that should be possible without breaking the bank.
Could not agree more! And yes, though due to the lack of specifications available for the ferrite rods I purchased, it ended up being more of a calculation of their permeability based on the measured inductance. I'll have another post soon that shows measuring the resonance frequency of these inductors with various types of capacitors, which is a fun exercise in parasitic capacitance and inductance.
Hey folks, author here. Appreciate the comments and discussion on the post! Happy to continue the discussion or answer any follow-on questions folks have about our investigation and resolution.
Would just be easier to implement an open source one from scratch given that most IOT modems are just (poorly written) software with an SDR anyway. CEVAwaves or RivieraWaves certainly is.
If it can be done for BLE, 802.15.4 and WiFi, it can be done for cellular; ORAN is enough for base-stations so it's not totally secret. But at the end of the day, aside from the stupid ITU protocols, LTE/5g isn't rocket science. It's bog standard OFDMA radio -- nothing fancy these days.
I ended up reverse engineering parts of Sony's Altair derived modems but got bored, maybe I should publish that
Good read thanks. To the point of having a open platform, they would probably lose their monopoly. I could then just spin up my own mobile network and provide service like a wifi network with any credentials and do what I want.
I guess there needs to be a big initial effort with lots of maintaining afterwards. If everything goes as expected the AIs could provide that in the future.
Not OP, but I’ve dabbled in nRF91 recently and found that once your application starts doing anything interesting (MCUboot, OTA, softSIM, etc.) the code size explodes. It is particularly difficult to keep TFM down to a manageable size. 1 MB of flash really doesn’t go that far these days.
Years ago I worked on the nRF52 series with the “old” SDK and felt I had much greater control. I understood the build system. Maybe I’m just grumpy and don’t like change…
That's a Zephyr thing. Same on STM32, add an otherwise trivial driver for some peripheral that has a bunch of dependencies, and then your codesize explodes by 60KB.
Nordic is one of the largest contributors to Zephyr though. I get the feeling that they are pushing hard to make it the de-facto RTOS for embedded stuff.
I feel like the whole Zephyr ecosystem is geared towards reducing "time to blinky on every devkit you have" at the expense of mid- to late-stage development efforts. Driver maintainers want their stuff to work out of the box, so they enable _everything_ and code size becomes the end customer's problem.
grumble grumble, I don't like where this is heading.
Great pointer! My sibling post in this thread references a few other blog entries where we have detailed using eDRX and similar low power modes alongside Connection IDs. I agree that many devices don't need to be immediately responsive to cloud to device communication, and checking in for firmware updates on the order of days is acceptable in many cases.
One way to get around this in cases where devices need to be fairly responsive to cloud to device communication (on the order of minutes) but in practice infrequently receive updates is using something like eDRX with long sleep periods alongside SMS. The cloud service will not be able to talk to the device directly after the NAT entry is evicted (typically a few minutes), but it can use SMS to notify the device that the server has new information for it. On the next eDRX check in, the SMS message will be present, then the device can ping the server, and if using Connection IDs, can pull down the new data without having to establish a new session.
Is "Non-IP Data Delivery" (basically SMS but for raw data packets, bound to a pre-defined application server) already a thing in practice?
In theory, you get all the power saving that the cellular network stack has to offer without having to maintain a connection. While on protocol layer NIDD is almost handled like an SMS (paging, connectionless), it is not routed through a telephony core (and hence sloooow). The base station / core will directly forward it to your predefined application server.
It has been heavily advertised, but its support is inconsistent. If you are deploying devices across multiple regions, you likely want them to function the same way everywhere.
An ad for... the IETF? All of the firmware discussed in this post is open source, and we even contributed DTLS Connection ID server side support to a popular open source library [0] so other folks can stand up secure cloud services for low power devices. Sure, we sell a product, but our broader mission is making the increasing number of internet connected devices more secure and reliable. When sharing knowledge and technology is in service of that mission, we do not hesitate to do so.
Author here -- thanks for engaging in the discussion! You won't find any pushback from us on using Zephyr -- we are contributors, the firmware example in the post is using it (or Nordic's NCS distribution of it), and we offer free Zephyr training [0] every month :)
I am somewhat surprised that the small loops would pick up a meaningful amount of noise, though I suppose meaningful always depends on the use case and tolerances. Do you have any references for how significantly this can impact inductor performance? Or is the primary concern just the rubbing and potential shorts?
Despite ferrite core inductors and loopstick antennas being old, fairly well understood technology, I have found there to be very little in the way of hands-on experiments with tangible results available. I'm hoping to continue testing various techniques and posting about them -- you've already provided some great variations for me to test out!
reply