I tried to use picoprobe to debug an nrf52 chip, it failed to even detect it.. All that’s officially supported is using it to debug a raspberry pi, and maybe if I added 100Ohm resistors to the lines I would have had better luck, but.. alas
> I tried to use picoprobe to debug an nrf52 chip, it failed to even detect it
I've literally got a Pi Debug Probe and a nRF52840 dev board on my desk, so I gave it a shot - and it works just fine. Make sure the core is awake when you try to connect for debug, or connect under reset; SWD goes to sleep with the rest of the chip.
> All that’s officially supported is using it to debug a raspberry pi
The Pi Debug Probe is a generic DAPlink probe, and will work for pretty much any Cortex-M part. I routinely use mine for debugging STM32 parts.
'Connect under reset' is an STM32 thing, nrf52840 can't really do that and the probe doesn't use hardware reset pin. Once the MCU is out of pin reset, Ctrl-AP can hold the mcu in soft reset, but that's the standard behavior.
The difference between Pico and Pi Debug Probe are those 100Ω resistors on CLK/DIO lines, so I guess it working for you means I need to try again with resistors soldered.
There's basically zero chance 100Ω resistors are contributing to your issues on a protocol that is host-clocked and can operate in the single kilobaud range.
Lower speed or try one of the other fifty debug firmware projects.
Okay i'm officially a dumbass - looking at the pinout i can clearly see Arduino pins and normal GPIO pins are mixed up on the board I used (seeed xiao rp2040). Arduino strikes again!
Just checked - of course if works fine on proper pins
Author here, thanks for posting! Happy to answer any questions and would love to hear about any use cases in which folks have dynamically enabled / disabled FPU functionality throughout program execution.
Hey Arjun and Sid! I am CTO at Golioth[0], a connected device cloud platform. Just wanted to say congrats on the launch, and wish y’all the best of luck! There is lots of complexity to be addressed, and it is always great to see more folks building in this space. Happy to compare notes any time!
Hey, thanks a lot! Really appreciate you reaching out!
I agree. There's so many cool things to do in this space, and so many unique ways to achieve them. We're excited to be here, and would love to chat sometime as well!
Good question! We wrote a few blog[0] posts[1] about the motivation for signy and how it is used in practice. The primary use case is complex devices with multiple MCUs and multi-protocol connectivity (e.g. Wi-Fi, Cellular, Bluetooth, etc.). In this context, each MCU may have different security capabilities, and manufacturing / provisioning may be simplified by storing a single set of credentials (e.g. a private key) in a single secure storage location, then using that key to generate a temporary signed URL that can be handed to the less secure domain for a scoped operation, such as downloading an asset. There are also more niche use cases, such as allowing an end user to access a private resource by generating a signed URL and sending it to a phone via NFC.
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.
[0] https://danielmangum.com/posts/risc-v-bytes-accessing-pineci...
reply