Cool! Earlier in 2025 I decided I wanted to design a CAN-FD connected motor controller for RRF / Klipper / custom firmware without any experience.
I'm a software eng now working outside of the tech sphere so not exactly an electronics expert. I know enough to be dangerous but thats about it.
I found Gemini to be pretty great at validating an exported KiCAD netlist against the relevant datasheets with a few caveats.
The RP2350 datasheet in particular was an issue due to its sheer size - bigger than the maximum token limit.
I got around this by extracting the relevant parts of the datasheet myself.
It sounds like you might have this well in hand but worth asking anyway. I assume you've had good experiences testing with MCU datasheets and not just passives / power components?
When it got something wrong it was wrong enough to be noticeable by a non expert and with iterations over the schematic and an incredible amount of time spent learning how to lay stuff out properly, I got a reasonably complex board (double sided, 6 layer, roughly 130 components) produced and fully functional first time.
I'm interested in trying this out on my working design and seeing what it comes up with!
If you can keep this cheap enough for hobby use (or pay as you go for example) and also find a way to validate or check for common layout concerns then that would be incredibly powerful.
It's great to see some genuinely useful use cases for LLM tech that isn't just "we replaced our support people with a shitty chat bot" :)
Not sure if you've heard of the Sur Ron or the Cake bikes but they're RAPID. I have a modified Sur Ron and it's way closer in performance terms to my Husky 701 than an e-mtb or similar (peak power to weight ratio of about 0.3hp/kg).
People put pedal kits on them to try and hide the fact it's basically a super light motorbike but in my experience it's not really suitable for riding on bike paths or trails.
Devices like in the OP are much more of a grey area as it's basically impossible to tell their power output / weight on an individual basis...
There's no DDoS prevention tool in play here (aside from that being Fastly's business).
Arista's default of having the TTL as part of the hashing function to calculate packet path means that any TCP connection that does not have a consistent TTL when it reaches this (source) ISP's routers can potentially be bucketed onto multiple different egress paths (transit or peering connections) onto different upstream SP's.
Because BGP works on the concept of AS Numbers rather than IP's (and because Fastly uses Anycast, which announces the same set of IP's from multiple POP's), it's possible that packets that leave the ISP network over different transit connections end up at different Fastly POP's, as each transit provider or peer will have a different route to Fastly's AS.
Fastly does not share TCP session information between POP's as I imagine at that scale it's massively prohibitive to do so.
The TCP RST happens because there is no established TCP session at the secondary POP which receives the TLS handshake packet, and because TTL is part of the hash function it will always end up following a different path (and therefore hitting a different datacenter, if routing stays consistent) if the TTL is reduced by 1.
It's generally deemed 'acceptable' in Anycast terms to cause a TCP RST when traffic switches from one POP to another, as this usually happens rarely, in response to changes in the path between two AS numbers.
For things like websites, browsers will usually just retry the connection, and as the path has changed and stays consistent, it starts to work and all you notice is a slight delay.
It doesn't work in this situation because the second packet with the reduced TTL is consistently routed to an 'incorrect' datacenter and breaks the TCP session every time, effectively dropping service to 0.
Used it last year. It's fun! You have to stand in the right spot though otherwise the plates extend under your feet which while I don't think it's dangerous, does feel a bit sketchy.
Eh? RTT between London and Sydney for example is around 300ms and testing that page, I see a 316ms RTT from Singapore (in London).
Theoretical minimum RTT's based on the speed of light for systems on the opposite side of the world is nice and all but doesn't take into account the realities of packet processing on the internet.
I'm a software eng now working outside of the tech sphere so not exactly an electronics expert. I know enough to be dangerous but thats about it.
I found Gemini to be pretty great at validating an exported KiCAD netlist against the relevant datasheets with a few caveats.
The RP2350 datasheet in particular was an issue due to its sheer size - bigger than the maximum token limit.
I got around this by extracting the relevant parts of the datasheet myself.
It sounds like you might have this well in hand but worth asking anyway. I assume you've had good experiences testing with MCU datasheets and not just passives / power components?
When it got something wrong it was wrong enough to be noticeable by a non expert and with iterations over the schematic and an incredible amount of time spent learning how to lay stuff out properly, I got a reasonably complex board (double sided, 6 layer, roughly 130 components) produced and fully functional first time.
I'm interested in trying this out on my working design and seeing what it comes up with!
If you can keep this cheap enough for hobby use (or pay as you go for example) and also find a way to validate or check for common layout concerns then that would be incredibly powerful.
It's great to see some genuinely useful use cases for LLM tech that isn't just "we replaced our support people with a shitty chat bot" :)