<re_irc>
<@jamesmunns:matrix.org> (don't forget your fences!)
<re_irc>
<@adamgreig:matrix.org> anyway it looks like the F4 CRC might not even support DMA, hmm
<re_irc>
<@adamgreig:matrix.org> oh, cool, no, it should work
<re_irc>
<@adamgreig:matrix.org> it stalls the write for the time taken to update the CRC
<re_irc>
<@adamgreig:matrix.org> not sure what would drive the drq though, might require some trickery
<re_irc>
<@theunkn0wn1:matrix.org> The F4's RM doesn't mention DMA at all for the CRC peripheral; yet a different ST document states that *all* members of the F4 family support CRC DMA
<re_irc>
<@adamgreig:matrix.org> so the crc peripheral in the f4 doesn't appear to generate drqs itself (e.g. none of the dma streams are for crc)
<re_irc>
<@adamgreig:matrix.org> but if you set up a mem2mem transfer on DMA2 and wrote into the CRC DR it seems like it could work
<re_irc>
<@theunkn0wn1:matrix.org> adamgreig: yeah, thats what dm00068118 says to do.
<re_irc>
<@theunkn0wn1:matrix.org> Though i think il not use DMA here; it would only make my code even more complicated
<re_irc>
<@adamgreig:matrix.org> yea
<re_irc>
<@adamgreig:matrix.org> if you can afford the handful of cycles to turn your &[u8] into u32s, I'd just do that, and then don't need to worry about alignment either
<re_irc>
<@adamgreig:matrix.org> and can do the same thing on the host side to compute the crc I guess
<re_irc>
<@theunkn0wn1:matrix.org> The most important thing is both sides being able to produce the same CRC
<re_irc>
<@theunkn0wn1:matrix.org> which only happens if i manually cast my u8 bytes to u32 in the driver side.
<re_irc>
<@adamgreig:matrix.org> hmmmm
<re_irc>
<@adamgreig:matrix.org> yo could use le_bytes in the device to make the u32, and then use LE on the host too, but
<re_irc>
<@adamgreig:matrix.org> actually if you do use BE bytes it should be possible to have the host compute byte-wise CRC and get the same value
<re_irc>
<@adamgreig:matrix.org> whether it's worth faffing with idk, it doesn't take long for your destop to turn the u8s into u32s
<re_irc>
<@theunkn0wn1:matrix.org> my current round trip time is ~40ms, which is probablymore than good enough for my application
<re_irc>
<@theunkn0wn1:matrix.org> and that is the time measured from when the host starts sending the reqest til the end of the response packet.
<re_irc>
<@adamgreig:matrix.org> hopefully the CRC is contributing very little to that
<re_irc>
<@theunkn0wn1:matrix.org> that is the hope in using the hardware CRC.
<re_irc>
<@theunkn0wn1:matrix.org> Don't presume you have any good ways of profiling embedded code do you?
<re_irc>
<@adamgreig:matrix.org> not sure about "good", heh
<re_irc>
<@theunkn0wn1:matrix.org> lol.
<re_irc>
<@adamgreig:matrix.org> I usually just read CYCCNT before and after regions of interest and report the value over rtt/uart/whatever
<re_irc>
<@adamgreig:matrix.org> for more serious profiling, set up ITM and dump over SWO, which can give you a time trace of various things
<re_irc>
<@adamgreig:matrix.org> what bitrate is the communication?
<re_irc>
<@theunkn0wn1:matrix.org> 115200
<re_irc>
<@theunkn0wn1:matrix.org> can go faster i think; both sides have DMA
<re_irc>
<@adamgreig:matrix.org> you could do a bit serial crc32 fully in software and complete it before the next bit arrives, doubt the crc is adding any meaningful overhead
<re_irc>
<@theunkn0wn1:matrix.org> i probably have more overhead in the three odd data copies i have >.<
<re_irc>
<@adamgreig:matrix.org> (I mean, presumably you have other things to do as well so don't want to waste time on crc, but i'm sure the hardware one is pretty quick in this case)
<re_irc>
<@adamgreig:matrix.org> yea :P
<re_irc>
<@adamgreig:matrix.org> probably converting the u8 to u32 is taking more cpu than the hardware crc...
<re_irc>
<@theunkn0wn1:matrix.org> Once decoding the cobs out of the DMA buffer, once validating the CRC, and once deserializing the request packet
<re_irc>
<@theunkn0wn1:matrix.org> though you know what they say: premature optimization is the root of all evil.
<re_irc>
<@theunkn0wn1:matrix.org> I did manage to shave 10ms off by changing the serialization from `json` to `cbor`
<re_irc>
<@theunkn0wn1:matrix.org> so i call that an absolute win.
fabic has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> theunkn0wn1: could you just feed each u8 as a u32 into the crc? like, just cast each one to a whole u32
<re_irc>
<@adamgreig:matrix.org> then do the same on the computer
emerent has quit [Ping timeout: 258 seconds]
<re_irc>
<@adamgreig:matrix.org> saves the copy and packing operations, and the cast is effectively free, you just write each u8 into the crc dr in turn
emerent has joined #rust-embedded
<re_irc>
<@grantm11235:matrix.org> Instead of creating a `&[u8]` buffer, could you create a `&[u32]` buffer and then casting it to a `&[u8]`
<re_irc>
<@grantm11235:matrix.org> That would solve your alignment problems, right?
<re_irc>
<@theunkn0wn1:matrix.org> the `&[u8]` is the result of reading from the USART; afaik i cannot change that.
<re_irc>
<@thalesfragoso:matrix.org> You can cast &[u32] to &[u8] before giving it to the DMA
<re_irc>
<@thalesfragoso:matrix.org> But with unsafe
<re_irc>
<@lachlansneff:matrix.org> Been trying to find some components, it's worse than I thought
<re_irc>
<@lachlansneff:matrix.org> I literally have to use a breakout board for the magnetometer because I can't find a reputable alternative that's just the IC.
<re_irc>
<@dirbaio:matrix.org> monacoprinsen: I'vehad really good success with the MPR121 (works great, super low power). It's not an MCU though, just touch
tokomak has quit [Read error: Connection reset by peer]
<re_irc>
<@lachlansneff:matrix.org> I just need it to do khrs with an IMU
<re_irc>
<@adamgreig:matrix.org> not much choice, they're just really easily confused by local hard/soft iron offsets, by the nickel in your ENIG plating becoming magnetised, by some nearby current flowing and creating a magnetic field, whatever
<re_irc>
<@lachlansneff:matrix.org> Can I shield them somehow?
<re_irc>
<@adamgreig:matrix.org> shielding magnetic fields is tricky but possible using mu-metal, but then you'd shield it from the earth's magnetic field too, so it somewhat defeats the purpose
<re_irc>
<@jamesmunns:matrix.org> Magnetometers are more often than not too noisy to use, ESPECIALLY indoors
<re_irc>
<@jamesmunns:matrix.org> (IME)
<re_irc>
<@adamgreig:matrix.org> it's a shame because in theory they give you a static, earth-referenced 3d orientation vector
<re_irc>
<@adamgreig:matrix.org> but in practice, yea, it's a mess
<re_irc>
<@adamgreig:matrix.org> but if you need to de-drift roll on your imu, what else have you got?
<re_irc>
<@jamesmunns:matrix.org> "Is that north? Or a filing cabinet?"
<re_irc>
<@jamesmunns:matrix.org> Yeah, outdoors they are more reasonable
<re_irc>
<@adamgreig:matrix.org> ehhh, can't say i've had the best experiences outdoors either, but depends so much on what metal you have nearby and what your calibration routine is and stuff I guess
<re_irc>
<@adamgreig:matrix.org> if it's inside a plastic case with no current currents it's probably better
<re_irc>
<@jamesmunns:matrix.org> We had them in avionics, but even with correction, they were either too noisy, or too laggy
<re_irc>
<@adamgreig:matrix.org> I think more serious applications use non-mems magnos like flux gate magnetometers and stuff, but they're big and expensive
<re_irc>
<@adamgreig:matrix.org> or two GPS antennas and get a bearing from their relative position, heh
<re_irc>
<@lachlansneff:matrix.org> Yeah, this is going to be used in a field in a model rocket, so I can't imagine too much metal around it.
<re_irc>
<@adamgreig:matrix.org> might do ok inside a model rocket, yea
<re_irc>
<@jamesmunns:matrix.org> To be fair, it's easier in an airplane than a helicopter. You rarely stop and turn around in a fixed wing :)
<re_irc>
<@adamgreig:matrix.org> do look in to calibration, you'll want to collect like a full ellipsoid of data as you rotate the rocket around and then you can use that to scale the readings at runtime
<re_irc>
<@adamgreig:matrix.org> maybe you can calibrate the accelerometer at the same time
<re_irc>
<@lachlansneff:matrix.org> Hmm, okay
<re_irc>
<@jamesmunns:matrix.org> Or, dip fully into sensor fusion
<re_irc>
<@adamgreig:matrix.org> even with sensor fusion you have to calibrate the magno first
<re_irc>
<@jamesmunns:matrix.org> and weight your mags appropriately so that they are used only as a slow bias
<re_irc>
<@jamesmunns:matrix.org> yeah, true
<re_irc>
<@jamesmunns:matrix.org> should have been "AND", rather than "OR", honestly.
<re_irc>
<@lachlansneff:matrix.org> I was planning on getting into ahrs
<re_irc>
<@adamgreig:matrix.org> sensor fusion is the algorithms you use to provide ahrs
<re_irc>
<@jamesmunns:matrix.org> Yeah, you can probably get "sensor fusion in a box" nowadays
<re_irc>
<@adamgreig:matrix.org> maybe some modern magnos will do the calibration onboard so they can just give you a calibrated heading?
<re_irc>
<@adamgreig:matrix.org> the last ones I looked at just give you an x/y/z field strength and had some very rough examples of how you might imagine turning that into a bearing
<re_irc>
<@adamgreig:matrix.org> but if you're on a rocket you'll probably just want the field strengths because the magno isn't going to be flat
<re_irc>
<@adamgreig:matrix.org> anyway yea just get a magno and accel and gyro on a pcb to start with, that's hard enough with today's stock, lol
<re_irc>
<@lachlansneff:matrix.org> :D
<re_irc>
<@adamgreig:matrix.org> the accel and gyro are by far the most important IMO
<re_irc>
<@adamgreig:matrix.org> like jamesmunns said, you just wanna use the magno to help de-drift/bias the other sensors
<re_irc>
<@lachlansneff:matrix.org> Awesome, sounds good
<re_irc>
<@jamesmunns:matrix.org> Yeah, the other magic AHRS does is get you processed data, like quaternions
<re_irc>
<@lachlansneff:matrix.org> That echos the info I was finding online
<re_irc>
<@jamesmunns:matrix.org> which might be harder to do if you don't have built-in floating point, but today that's so cheap, the value is relatively low.
<re_irc>
<@lachlansneff:matrix.org> The MCU I'm using has an FPU, so I should be good there
<re_irc>
<@jamesmunns:matrix.org> I'm sure korken89 or Mara have opinions on sensors and Rust, they are both doing quadrotor things
<re_irc>
<@jamesmunns:matrix.org> (sensor fusion is usually just extended kalman filtering + different weights depending on the speed/accuracy/precision of your different sources)
<re_irc>
<@jamesmunns:matrix.org> It is probably THE COOLEST application of matrix math and statistics tho, IMO.
<re_irc>
<@lachlansneff:matrix.org> I'll have to look into how it works!
<re_irc>
<@jamesmunns:matrix.org> EKF is a bit different, but the concepts are the same
<re_irc>
<@jamesmunns:matrix.org> There was a research paper I liked for sensor fusion, but I've lost the link
<re_irc>
<@jamesmunns:matrix.org> Sensor fusion generally adds the ability to weight measurements based on how often they occur, vs how precise they are (in a global sense)
<re_irc>
<@jamesmunns:matrix.org> So you might describe accelerometer readings as happening very often, and being locally precise (but drift over time), but GPS readings happen slowly, and are not sub-meter precise, but globally precise (you know you are in a 10m bubble)
<re_irc>
<@ryan-summers:matrix.org> Sensor fusion is also incredibly hard and finicky. We fought with it for a year or two using an IMU and eventually just bought an IC that reported the final results to us instead, which I believe just did the kalman filtering internally
<re_irc>
<@ryan-summers:matrix.org> I wasn't the one originally implementing the fusion, but I did the swapover to a device that just reported the yaw/pitch/roll etc. to us directly, and our number of errors went down substantially (from like, almost always wrong, to almost never wrong)
<re_irc>
<@jamesmunns:matrix.org> Yeah
<re_irc>
<@jamesmunns:matrix.org> that's the tricky part, the coefficients you use for uncertainty etc. are sort of an art, and down to the actual devices you use.
<re_irc>
<@jamesmunns:matrix.org> We derived ours with known-good test data vs the measured equipment
<re_irc>
<@jamesmunns:matrix.org> but if you were going blind, you can have rapidly de-tuned systems
<re_irc>
<@jamesmunns:matrix.org> sort of like tuning PID loops
<re_irc>
<@ryan-summers:matrix.org> Yeah - just be aware of what you're jumping into when taking on a sensor fusion task
<re_irc>
<@jamesmunns:matrix.org> Yeah, truth, truth
<re_irc>
<@jamesmunns:matrix.org> you are bringing back long conversations with a EE and matlab regressions which I had blocked from my rosy memory :D
<re_irc>
<@ryan-summers:matrix.org> A lot of people think that a gyro + accelerometer + magnometer just gives you everything you ever need, and it could not be further from the truth
<re_irc>
<@jamesmunns:matrix.org> We live in exciting times :D
<re_irc>
<@ryan-summers:matrix.org> Ow
<re_irc>
<@adamgreig:matrix.org> a lot of COTS products won't be great for a rocket application though
<re_irc>
<@dirbaio:matrix.org> oof
<re_irc>
<@adamgreig:matrix.org> especially a small solid, you'll probably have high take-off acceleration that will go beyond its dynamic model
<re_irc>
<@ryan-summers:matrix.org> True - we used ours on a submarine, and still needed to do magnetic calibration for hard and soft iron distortion etc.
<re_irc>
<@jamesmunns:matrix.org> Yeah, "out of range" accelerometer readings will add up to drift, FAST
<re_irc>
<@adamgreig:matrix.org> doing sensor fusion for "tracking a VR headset", where the position changes slowly but you want attitude error low, can be a very different task than a rocket where you expect extreme position changes but your dynamic model is very predictable
<re_irc>
<@jamesmunns:matrix.org> and even if you are correlating to GPS position, the Z direction is typically WAY less accurate than X/Y
<re_irc>
<@adamgreig:matrix.org> a _lot_ of sensor fusion is knowing your dynamic model and predicting where you think you should be, which is way easier for a ballistic object undergoing some acceleration than for someone's head
<re_irc>
<@jamesmunns:matrix.org> like, 10-20m instead of 3-5m expected accuracy, IIRC
<re_irc>
<@adamgreig:matrix.org> so, it's a lot of work, but you can usually outperform integrated commercial solutions if you have a good handle on your own dynamics
<re_irc>
<@adamgreig:matrix.org> jamesmunns: for a rocket, a great sensor is a barometer, like MS5611, which gives you ~10cm accuracy altitude measurements up to maybe 10km
<re_irc>
<@ryan-summers:matrix.org> Yeah, my warning is largely targeted at makers or solo engineers, and not professional engineering teams.
<re_irc>
<@adamgreig:matrix.org> of course you need to calibrate out atmospheric pressure on the day (or just use it relative to ground level), but it's way better than GPS altitude
<re_irc>
<@jamesmunns:matrix.org> Oh yeah, if you are only caring about delta-elevation, baro alt is great for that
<re_irc>
<@adamgreig:matrix.org> ryan-summers: all the professional engineering teams I can think of definitely just buy in an IMU in a box, lol
<re_irc>
<@jamesmunns:matrix.org> Yup :D
<re_irc>
<@jamesmunns:matrix.org> Or at Garmin, we had our own team that made the IMU in a box
<re_irc>
<@adamgreig:matrix.org> jamesmunns: well, you feed the baro and the GPS and everything else into your sensor fusion and it spits out the best altitude, right :P
<re_irc>
<@ryan-summers:matrix.org> Yeah - I remember buying a nice $1200 IMU and realizing how worth it it was
<re_irc>
<@ryan-summers:matrix.org> (For an engineering project)
<re_irc>
<@jamesmunns:matrix.org> Yeah, most of those are car/plane oriented tho
<re_irc>
<@adamgreig:matrix.org> you can spend that just on the mems sensors, no fusion involved, and it's still so worth it, lol
<re_irc>
<@jamesmunns:matrix.org> too hefty for a quadrotor, maybe for a hexa+ rotor craft
<re_irc>
<@adamgreig:matrix.org> wild that you can spend $1 or $1000 on a 3-axis accel+gyro and the latter is barely any better on the datasheet
<re_irc>
<@adamgreig:matrix.org> but wow, it turns out gyroscopes are _heavily_ affected by linear acceleration, and the expensive ones are way better about it
<re_irc>
<@adamgreig:matrix.org> of course you can try and model that in your sensor fusion....
<re_irc>
<@adamgreig:matrix.org> I'm assuming Lachlan Sneff's project does not have much of a volume or mass or financial budget for electronics though, so most off the shelf IMUs are probably out of budget..
<re_irc>
<@jamesmunns:matrix.org> adamgreig: Oof, I have a long story about avionics and altitude, but that's an "over a beer" kind of shaggy dog story.
<re_irc>
<@adamgreig:matrix.org> I look forward to when we can next get beers, lol
<re_irc>
<@ryan-summers:matrix.org> I had an altitude-triggered camera project once. It was easy though because it was like, if atmo == 0, trigger
<re_irc>
<@adamgreig:matrix.org> my fave rocket-related one is that barometers will get _very_ confused as you go through a mach transition
<re_irc>
<@jamesmunns:matrix.org> lol
<re_irc>
<@adamgreig:matrix.org> as the shock wave travels down the vent port on your airframe body that's feeding the barometer you'll get an inversion
<re_irc>
<@ryan-summers:matrix.org> That would likely explain the extensive trigger validation process we had
<re_irc>
<@adamgreig:matrix.org> so you had really better be ignoring the barometer during the sub-to-supersonic transition
<re_irc>
<@adamgreig:matrix.org> it's OK again once you're supersonic
<re_irc>
<@ryan-summers:matrix.org> I always wondered why the spec'd such a rigorous verification check on the trigger
<re_irc>
<@lachlansneff:matrix.org> jamesmunns: Would love to hear this whenever oxide is running again haha
<re_irc>
<@adamgreig:matrix.org> classic thing with model rockets is they are set to trigger parachutes on apogee, which is detected as an inflection point in the barometric altitude
<re_irc>
<@lachlansneff:matrix.org> Ah, so if they're going supersonic, it triggers then
<re_irc>
<@adamgreig:matrix.org> good oops
<re_irc>
<@adamgreig:matrix.org> the moment you go supersonic is a bad time to deploy parachutes, lol
<re_irc>
<@jamesmunns:matrix.org> :D
<re_irc>
<@jamesmunns:matrix.org> "you are not going to space today"
<re_irc>
<@adamgreig:matrix.org> it turns out making supersonic-capable parachutes is a whole different hobby...
<re_irc>
<@jamesmunns:matrix.org> I'm not sure if anything I've built has gone supersonic
<re_irc>
<@jamesmunns:matrix.org> I've SEEN flight data up to juuuuuuust under mach 1
<re_irc>
<@jamesmunns:matrix.org> Maybe if one of the new-gen supersonic jet startups decides to put Garmin kit in them, I can say my software has gone supersonic (if they haven't squashed all my commits out by now)
<re_irc>
<@lachlansneff:matrix.org> Used to work at Garmin?
<re_irc>
<@jamesmunns:matrix.org> Forever ago, now :)
<re_irc>
<@jamesmunns:matrix.org> doing transponder/TCAS systems
fabic has quit [Ping timeout: 272 seconds]
<re_irc>
<@firefrommoonlight:matrix.org> @ jamesmunns I can take it to 1.2 if it goes on a phone or STM/nrf dev board
<re_irc>
<@lachlansneff:matrix.org> In what cases should I add an external oscillator to an MCU if there's an internal one? The datasheet mentions that the internal oscillator is less accurate, but how much would that matter?
<re_irc>
<@firefrommoonlight:matrix.org> For LSE: if you want to use a reliable clock or calendar. HSE: USB, Ethernet, RF etc - anything high freq or with precise freq requirements. Note that sometimes there are tricks for USB etc to use LSE or USB signal, where you can still use internal
<re_irc>
<@firefrommoonlight:matrix.org> Eg if you use RTC to wake up from low power mode, internal LS is fine. If you want to display time and date over weeks or .months, internal will drift too much
<re_irc>
<@firefrommoonlight:matrix.org> Using a radio and Ethernet? You need HSE. USB? Maybe. I2c/timers only? Internal HS is fine
<re_irc>
<@adamgreig:matrix.org> I'd definitely stick one on for doing state estimation/sensor fusion
<re_irc>
<@adamgreig:matrix.org> Integrating accelerations into velocities and positions requires knowing dt, so 1% error in clock gives 1% error in velocity and so on
<re_irc>
<@firefrommoonlight:matrix.org> Btw, there's a rust lib for kalman filtering that works on nostd, but I don't know if it's robust enough for this
<re_irc>
<@adamgreig:matrix.org> Check datasheet for the rc accuracy though, they vary a lot and maybe it's already good enough... I'd probably stick an hse on anywat
<re_irc>
<@firefrommoonlight:matrix.org> Called 'filter'
<re_irc>
<@adamgreig:matrix.org> Use a small oscillator instead of needing a huge xtal and annoying load capacitors though
<re_irc>
<@firefrommoonlight:matrix.org> I'd always go smt MEMs if you can
<re_irc>
<@firefrommoonlight:matrix.org> Assuming you're not using something like Stm's clock recovery system
<re_irc>
<@theunkn0wn1:matrix.org> afaik, im using whatever the default configs for the f446 are.
<re_irc>
<@theunkn0wn1:matrix.org> I see there is this open `X3` pinout for a HSE on the nucleo board, though im not sure what kind of occilator i need to put there to enable USB (If i understand it correctly that one is required)
<re_irc>
<@adamgreig:matrix.org> firefrommoonlight: I mean, a small crystal oscillator module, instead of a plain crystal; there are some downsides to MEMS instead of crystals (but probably totally fine here too)
<re_irc>
<@lachlansneff:matrix.org> Why mems over crystals?
<re_irc>
<@firefrommoonlight:matrix.org> Lower power/more accurate. That said... You won't notice a diff, and crystal is fine. But if you have a choice ...
GenTooMan has quit [Ping timeout: 258 seconds]
<re_irc>
<@firefrommoonlight:matrix.org> When in doubt, add an external. Worst case, you very slightly increased cost and complexity
<re_irc>
<@firefrommoonlight:matrix.org> And power consumption
<re_irc>
<@firefrommoonlight:matrix.org> If you're confident you don't need one, skip it
<re_irc>
<@adamgreig:matrix.org> firefrommoonlight: More accurate?
<re_irc>
<@monacoprinsen:matrix.org> dirbaio: Thanks, so how does this work.
<re_irc>
<@monacoprinsen:matrix.org> You could use it together with any MCU? For example stm32f303
<re_irc>
<@dirbaio:matrix.org> Works over i2c
<re_irc>
<@monacoprinsen:matrix.org> Practical, will give it a go.
<re_irc>
<@firefrommoonlight:matrix.org> Sorry about spreading bad data guys!
<re_irc>
<@firefrommoonlight:matrix.org> (I'd expect either MEMS or xtal to be much better than an internal oscillator, but for many uses, internal is good enough)
<re_irc>
<@adamgreig:matrix.org> I think you are right about lower power though, and often much smaller packages too
GenTooMan has quit [Ping timeout: 248 seconds]
GenTooMan has joined #rust-embedded
<re_irc>
<@gulwath:matrix.org> Lachlan Sneff: If you plan on pursuing the magnetometer approach, good calibration is essential, especially when working with cheap cots components. A programmable 3d Helmholtz coil setup for calibration purposees is helpfull here. Data fusion (extended Kalman) in Kombination with accelerometers works well,...
<re_irc>
... provided you have good modeling of your system. If your instrumented model is spinning be aware that spinning conductors (the hull of your Model for example) will result in eddy currents that in turn dephase the external earth magnetic field when measured inside, even if the hull is non magnetic. Place the batteries as far away as...
<re_irc>
... possible. The upside is that the resulting System is very robust against mechanical stress. Here is an example we did for ESA that survived >20.000g of acceleration during launch and that was used for determination of aerodynamic prooerties of a small scale model of a space probe fired from a powder gun. You can see the supersonic...
<re_irc>
<@grantm11235:matrix.org> That is at 1mhz btw
<re_irc>
<@grantm11235:matrix.org> The same thing happens at 100khz. If I read `RX_ADDR_P1` I get all zeros too, even though it should be `0xC2C2C2C2C2` on reset
<re_irc>
<@grantm11235:matrix.org> Looks like that chip is dead 😭
<re_irc>
<@adamgreig:matrix.org> dirk-dms: very cool! looks like a fun test!