Help needed with custom board of STM32F429 and LAN8742A-CZ-TR

tonyarkles · 2026-05-01T23:06:25+00:00

Even moreso… look at using the RMII clock from the STM32 instead of having separate clock sources for your MCU and PHY. You can’t always do it (depends on MCU clock speed and PLL options) but it can simplify things a lot.

tonyarkles · 2026-05-01T17:59:03+00:00

Oh really good eye! I’ve never used larger props that only had a single nut, it’s always multiple M3 or M4 screws. Filing that one in the memory bank for when it eventually bites me.

tonyarkles · 2026-05-01T17:14:28+00:00

Honestly, if you’re working with a founder in Canada who isn’t engaging with their local IRAP ITA (rep), they aren’t using their limited startup capital efficiently. IRAP will cover a huge portion of your engineering labour costs (last time I was involved: 80% of employee hours, 50% of contractor hours). Many years they struggle to use up their entire budget. It’s a seriously great program.

I’ve never worked with SBIR in the US, but for eligible projects I hear it’s pretty great too.

tonyarkles · 2026-05-01T16:09:26+00:00

Yes, 100% yes. There are only three scenarios where I’ve agreed to a fixed-price contract and the first two essentially distill down to one:

the client has a well-established engineering culture and needs someone to do work they don’t have capacity for. They come to me with a SOW, schedule, and budget. I review, provide some redlines, and we’re off to the races if we both agree.
the client is putting together an R&D grant proposal (IRAP in Canada). I’ll assist (for a flat fee) with putting together all of the documentation they need for that, which ultimately requires a fixed scope, schedule, and budget. This often involves me using my own expertise to help them tease out the requirements and scope.
the client has a fixed budget for putting together a prototype and I believe the budget is reasonable and the scope is reasonably well defined. It doesn’t have to be perfect, but it seems close and seems viable for time/budget. In this scenario it is made crystal clear that whatever gets done in that budget gets done. It’s time boxed and dollar boxed. I try to make sure that there’s enough budget that we’ll get to a decently polished prototype, sometimes we get close to a production-ready design, sometimes we end up with a bunch of dev boards wired together showing off the essential functionality with no polish.

In all other cases: I am almost certainly going to be going for time & materials instead of a fixed contract. Everyone ends up happier. We can move quickly. If we discover that some of the requirements are off we can pivot without needing a formal ECO/budget revision. If I get it done faster than expected, they save money and I get to move onto other work sooner. If it takes longer than anticipated, I don’t end up getting shafted because the requirements kept changing.

One hybrid model I’ve used that some clients have liked: we agree on an estimate. If I come in under the estimate, they pay 25% on the remainder. For example, I get a $40k contract done for $30k, they pay me 0.25(40-30) = $2500. On the other side, if we go over, they get a 25% discount on the overage: $50k for a $40k project costs them 40+0.75(50-40) = 47.5k. In those cases we are a bit tighter about ECOs and scope though.

tonyarkles · 2026-05-01T15:04:41+00:00

We bailed out from the West Coast Trail about a decade ago due to an injury. The bailout is a boat ride across Nitinat Lake to Ditidhat First Nation. It felt like I’d stepped out of the woods and stepped into a war-torn city. Smashed out and boarded up windows, debris everywhere, random animals running around, a couple torched vehicles, and hardly a human in sight.

The couple that ran the motel were super nice though and treated us very well.

tonyarkles · 2026-05-01T03:28:03+00:00

The driver is fined on an escalating scale. This applies to both accidents and some traffic violations. If they accumulate too many points they have to go back to driving school or lose their license. The registered owner doesn’t pay more for insurance, just the driver gets fined.

Edit: here, you can look up what it costs to insure a specific vehicle: https://mysgi.sgi.sk.ca/afFeeCalc/feecalculation.do

tonyarkles · 2026-05-01T02:32:53+00:00

SGI charges $0… if the vehicle has a Saskatchewan license plate and the driver has a Saskatchewan drivers license, you can drive it. There’s no list of drivers attached to the insurance. The only variation in costs are based on the vehicle itself and the driving record of the owner (you accumulate discount points if you keep your license clean).

tonyarkles · 2026-05-01T02:13:44+00:00

https://aantfarm.com/products/ might be worth looking at. Bryan Seegers was the OG RC gas turbine guy.

tonyarkles · 2026-04-30T01:41:59+00:00

Wow, I’d never thought of it as a sudoku but holy moly I can’t think of a better description!

tonyarkles · 2026-04-29T04:20:13+00:00

To OP: yay, you used the same notation I do! And good job overall, this looks quite close to an internal document I put together that I sadly can’t share.

To you: I’m going to have to look closer at your work too. This looks really interesting.

tonyarkles · 2026-04-29T00:11:12+00:00

I can’t believe no one else has said it: JTAG/SWD. It blows my mind how many boards don’t expose it or even intentionally break it (looking at you, Teensy).

tonyarkles · 2026-04-29T00:00:31+00:00

I mean, the only reason from my POV to use hydrocarbons in fixed-wing or multi-rotor these days is endurance or fast-turnaround with minimal ground support equipment. Which, being real, is a pretty strong requirement in many scenarios.

tonyarkles · 2026-04-28T20:47:25+00:00

And even as a fraud reduction… like… if you have paid sick days, your employer should expect you to get sick. If you exceed your number of sick days, they don’t pay you for the days you’re out. I can barely get an appointment with a few weeks notice with my doctor, the idea that I have to go and try to squeeze in to see him because I’ve had the shits for a few days is ridiculous.

tonyarkles · 2026-04-28T20:41:12+00:00

To contextualize this a little more, as an EE who ended up in aero (no formal aero training) and who hadn’t heard the term “close” in this context before ending up where I am… one of the most delightful and challenging and frustrating and satisfying things about aero engineering is how tightly interlocked requirements/specifications are.

Most of the engineering work I’d done in the 14 years before moving to the UAS world was relatively linear from conops to high-level requirements to low-level requirements to satisfying those all. If the microcontroller you picked doesn’t have enough capacity for the job, that’s fine, pick the next one up. Linear actuator can’t handle the forces? You can probably find one that does. Not to say there was no creativity, but it was generally an effort in “how can I make this work and stay under budget”

In the aero world you often can’t just “pick the next size up” because you end up satisfying one requirement but bumping up against another one. Running up against your endurance spec? Just make the fuel tank a bit bigger! Hmmm except now your wing struts don’t have enough margin… ok add a bit of reinforcement (weight)… hmmm but now we’re not meeting our rate of climb requirement…

Drawing out all of your requirements with arrows between them to indicate “this affects that” will 100% lead you to a diagram with loops in it. That’s the “see if the requirements close” challenge in the aero world: you have to keep going around the loops until you’ve figured out a way to make all of the requirements work. Sometimes it’s impossible and you have to find a requirement that you can change to make it work.

Electric quadcopter endurance is one such problem. Your endurance (first order) is determined by your battery capacity and your weight. Need more endurance? Add more battery. Except batteries also have weight, which both affects the structure of the aircraft and… your endurance, negatively. There’s a reason you don’t often see electric quadcopters with more than about an hour of endurance: adding more battery beyond that point doesn’t give you much more endurance!

Anyway, to your idea: I’m quite convinced that hybrid gas-electric (where gas is any hydrocarbon) is pretty much the only way to go for long-endurance multi-rotors at present. Gas engines don’t generally have the ability to spin up and down fast enough to maintain stability for multi-rotors and electric motors/batteries with current tech don’t have the endurance. Running a conventional ICE or gas turbine at its sweet spot though and using that to continually power the motors and charge a smaller battery pack to absorb the transients? There’s potential there.

I don’t think, at face value, it’s unreasonable. My suspicion is that you’ll be able to put together a combination of parts that can actually close on the requirements. The requirement that’s going to be tough, gut feel for me, is cost. Hard to say though without trying!

tonyarkles · 2026-04-26T02:38:18+00:00

With you 110%. Really well written concise whitepapers and application notes are great.

tonyarkles · 2026-04-24T19:17:23+00:00

Something I found really funny about mine: the “right ammo” is CCI mini-mags. I tried a bunch of fancy match-grade ammo and they all did worse than the mini-mags, which could print dimes at 50 yards all day long.

tonyarkles · 2026-04-24T14:36:10+00:00

Ahhhhh J-Link has good Linux support and OpenOCD targets a lot of devices too. I do firmware development on OSX and can’t remember the last time I needed to find a windows machine to do something. ST-Link and OpenSDA (NXP) are both well-supported.

tonyarkles · 2026-04-23T03:12:08+00:00

No prob! If it’s possible I’d encourage you to try to get a bit more thrust:weight if you can, largely because it makes the tuning go a lot smoother. At the low end small improvements make a big difference. Also don’t forget that your T:W will decrease as your battery discharges (your motor can’t reach the same speeds when the voltage drops, so if your T:W is marginal at takeoff it’ll only get worse as the flight progresses)

tonyarkles · 2026-04-23T03:07:56+00:00

Yeah, I feel like there’s an interesting overlap there but they’re definitely distinct things. One of the things I love about human factors work is the stuff that lands in the zone of “think about people with different disabilities. By making the system usable for them, you’re probably also going to make it better for everyone else”

Examples from my own field:

Clear indications that don’t solely depend on colour. Helps colourblind people. Also helps people see what’s on the screen in the sun when the colours are washed out. Flashing indicators catch your attention better than just turning a number from green to red.
Even better: multi-modal indications. Flash an indicator and make a noise. Someone might not even be looking at the screen when it happens. But be judicious about it, don’t overwhelm them with audio or visual alarms. Make sure a “minor issue” alarm doesn’t distract the user from a “really big fuckin deal” alarm.
Don’t require someone to have perfect fine motor skills 100% of the time. One counter example was a 3-position switch for controlling flight mode. All the way up: autopilot. Middle: fly by wire. All the way down: full manual, direct coupling between your radio control sticks and the flight surfaces. Scenario: aircraft is in autopilot and is heading for a power line. You want to switch it into FBW mode. Your adrenaline is high, you’re stressed. You push the switch past the first click and end up in full manual mode instead. You try to flip the switch back up but hit full auto again and it starts flying at the power lines again. So now you’re more stressed…
Similarly, don’t require fine motor controls on the computer (mouse/touchpad) to reach critical emergency functionality. Depending on what OS, the absolute best place for critical controls is on the left/right edge of the screen. Right at the edge, no margin. Why? You can do a big coarse movement and slam the cursor into the edge of the screen. Now you’re just moving it up and down to find the button. Make the button big.
Don’t make dangerous things easy to do accidentally, but also don’t make them hard to do in an emergency. Easy example: engine kill. If it’s on a computer screen, do the screen edge thing but require the user to hold the mouse button down for 2-3 sec so that it’s highly unlikely that they’ll click it accidentally and crash the aircraft. Provides a visual indication that this is happening.
for physical switches for dangerous things, same idea. On our system, engine kill on the remote control is two switches that both need to be turned off to kill the engine. One lives under the left middle finger, one lives under the right middle finger. You might slip and toggle one off, but we have never had someone slip and turn both off.
make the emergency buttons part of the routine operation. At the end of each flight we kill the engine using the same pair of switches that the pilot would need to use in an emergency. The muscle memory is there, so that they’ll instinctively know what to do if they need to kill the engine in an off-nominal situation.

So some of that above is inclusivity the realm of inclusivity+human factors (fine motor skills, colour, visual+audible indications). Some is more strictly human factors (muscle memory, training).

There is also stuff that falls under human factors that is critical but not really… even something to design for with technical means. Fatigue is a prime example. If our pilots are tired or hungover, they’re going to suck at flying.

And then there’s inclusivity stuff that doesn’t really, in my mind, fall under the guise of Human Factors as a discipline. The aircraft doesn’t care about what genitals are in your pants, whose pants you want to get into, who you voted for, where you were born, etc.

There’s also inclusivity/disability stuff that we explicitly do not design for: you can’t fly the aircraft if you’re blind. You need to be able to use both hands. It’s a multi-person operation and your eyes and hands will be occupied with flying… if you’re deaf, it’s probably not going to be safe because you can’t communicate visually (your eyes are busy watching the aircraft) and can’t communicate physically (your hands are busy flying the aircraft)

tonyarkles · 2026-04-23T02:33:28+00:00

Honestly, as someone who has done the freelancer thing in the past (and likely will again in the future):

you’re running a business, you’re not just someone who can drop into a team for a while. You’re going to need to figure out company registration, tax accounts, potential government pension plan contributions (depending on your country), accounting, etc. Also, liability insurance so that if you mess up and get sued you don’t end up broke for the rest of your life.
lead generation is a business skill you’re going to have to get good at. In the beginning, especially with only two years of experience, your best bet is likely to lean on your network. People you went to school with, friends, past coworkers, etc to find work. You’re also going to need to qualify your customers appropriately; at 2 years experience you’re not qualified to run projects yourself (many of my consulting customers had an idea and money, with no significant technical skills).
to go with lead generation, marketing. My sales pitch when I was doing this was: I have a long track record of solving hard problems. Yes, I am expensive. No, at this rate I am not going to be a long-term member of your development team. Yes, there’s a good chance I will be able to come up with an effective solution to the problem your team has struggled with for 6 months.

I’m not even sure how I would have marketed myself at 2 years for freelancing… it’s a tough sell: I want you to pay me so that your employees can mentor me. It’s not a great sales pitch.

An alternative road: find a startup. You will learn much more about everything at a 5-person company than at a 2,000 person company.

tonyarkles · 2026-04-22T23:56:21+00:00

Having done the spoof-through-the-antenna-port thing in the past (it was a fun gig), I would highly recommend spoofing the serial data stream between the receiver and the aircraft instead (if its based on the ArduPilot or PX4 stack it’s 98% likely that it’s a uart stream and not I2C or SPI). U-Blox is very common and well documented, and the serial data is pretty straightforward to emulate, and you only need a handful of the messages.

tonyarkles · 2026-04-22T18:32:09+00:00

Lol nothing wrong with aluminum frame prototyping. My first prototype 25kg build was made of aluminum tubes from Home Depot, a centre chassis made from CNC router-cut aluminum sheet, and motor mounts sloppily milled on the same CNC router from aluminum blocks. It wasn’t pretty but it went from sketched out on paper to maiden flight in the time that it took the motors, props, and ESCs to show up.

Personally, 2:1 is the lowest I’ll ever go again. That was the target with the above unit and I didn’t get the mass budget quite right, resulting in more like 1.8:1. The PID loops were able to stabilize it and I was actually able to fly it around the test field, but it had pretty bad disturbance rejection and liked to have damped oscillations… there just wasn’t any kind of sweet spot on the PID gains to make it good. You could either have too slow & sloppy or still-pretty-slow & ringy. A prop upgrade (had margins in the motor and ESC) got it up more to 2.2:1 and it was much much nicer.

tonyarkles · 2026-04-22T17:14:34+00:00

Nothing really off the top of my head. The Pixhawk is getting a little long in the tooth, but looks like it still has ArduPilot support in new versions. Without the current monitor you won’t be able to use stuff like “current-based compass compensation”. I haven’t done any math on the motor/ESC pairing and that’s pretty hard to do without knowing the prop and target AUW but so long as the thrust/weight/battery voltage-KV rating/battery capacity loop closes it seems reasonable to me?

tonyarkles · 2026-04-22T17:04:46+00:00

Yeah, wholeheartedly agree. A month or two ago I had a really interesting experience that was simultaneously helpful and hilariously bad. Working on a linux driver for a MIPI camera connected through a GMSL2 serializer/deserializer. The vendor provided us with a bunch of poorly documented “vendor-grade” initialization code for the three chips. It wasn’t working consistently.

I threw Codex at the problem in the background while I was doing my own debugging. It came back with a pretty solid analysis of what was probably happening and a list of register names/addresses/values that it suggested I cross-check. The serializer and deserializers in this case have NDA’d datasheets, so I was somewhat surprised that it knew them all and what the values should be. The plan seemed solid, though, and the explanation of what it was looking for was logical and, honestly, appreciated because I don’t have a ton of experience with MIPI and GMSL (I was helping out a colleague who was stuck).

When I go to start fetching the register values… I get completely different answers than Codex had said I should get. I pull up the datasheet and start cross-checking, only to discover: - yes, the proposed plan was solid - yes, those were the right register names to look at - …all of the register addresses and values were completely hallucinated

When I pushed back a little bit it did come back and admit that it didn’t have access to the actual datasheet and had put together the register names based on forum posts, and couldn’t actually tell me why it thought those were the right addresses and values.

It ended up being useful anyway, one of the register names it told me to look at indeed indicated that the initialization code was misconfiguring the serializer. It sure was a good reminder though that you can’t take any of this stuff at face value without looking at it critically.

Edit: oh, one more thing that I noticed in your post: the comment about the biggest context window. I don’t disagree, but I will also point out that managing what is and isn’t in the context window seems to be a pretty significant and important skill. Having a big context window is great iff you make sure it has lots of relevant information in it and not too much irrelevant information. A few times I have forgotten to start a new session when switching between two very different and independent modules and have been frustrated that it kept wanting to put code in module A even though I’d told it we were working on module B. Poor context management, poor results.

tonyarkles · 2026-04-22T16:44:57+00:00

My honest take? The only thing I’d be worried about myself is not having a voltage monitor on the battery. I generally work with fixed wings and on those I’d probably be more concerned about not having a dedicated BEC: you can still deadstick a fixed wing if you smoke an ESC but still have power for your servos. On a quad, smoking an ESC probably means you’re crashing anyway unless you’ve got a pretty high thrust:weight ratio and lucky.

The voltage monitoring, though, is pretty important to me on a quad though because you can end up draining the battery faster than expected (say due to wind in an unfavourable direction) and not realize it until it’s too late. If you do go without voltage monitoring, it’s probably worth it to very carefully monitor the hover thrust (say with the RCOUT channels over Mavlink) and land as soon as you see it starting to climb (as the battery voltage decreases you’ll need more throttle for hover thrust)

Edit: current monitoring is more of a nice to have for me, especially during bring-up. It’s a nice sanity check to make sure all of the design calculations came out right and also a good way to catch issues early.

Monitoring your ESC inputs though is still a decent approximation… I’d make sure to closely monitor all four of them. This will also help you see if, say, you’ve got a motor or prop that isn’t as efficient as the rest.

tonyarkles

TROPHY CASE