blutack

Great project!

If you want a hardware upgrade it's actually reasonably inexpensive to build something direct drive (which is how the real sub-30kg ones work). This gives you many advantages over the plastic gear type including a much faster response time and more accurate positioning.

Look for "gimbal motors", basically a large skinny pancake brushless motor. Combine those with a storm32, simplebgc or odrive and a magnetic encoder. A 3D printer will help.

You can also have a look at low cost suppliers of cheap UAV stuff if you want something fully integrated for you. A basic Gremsy, Viewpro or Siyi isn't that much more than your Amazon thing. Various software bugs but they can be worked around. The DJI units can sometimes be had used and some of the protocols have been RE'd already.

Presumably also open circuit not rebreather given this was mid 90s. It's a pity the article doesn't detail their dive plan, the gas quantities must have been staggering.

Nowadays this type of diving would be done using an eCCR (and backup open circuit), where some software on a microcontroller controls the amount of oxygen in a breathing loop. A scrubber (hopefully) removes the CO2. Changing the gas mixture as you go is required to reach these sorts of depths because oxygen becomes toxic at pressure, and gas density itself can cause issues with breathing.

Luckily it's supported by Valetudo so it can go back to work.

https://valetudo.cloud/pages/general/supported-robots.html#i...

This might be a US/EU difference. It's pretty popular in the EU still, although some of the market has been taken by various Simulink to C tools.

Every Rolls-Royce gas turbine FADEC runs ADA binaries on a custom processor [1].

It's also used extensively at Airbus. Lots of DO-178C (safety critical aerospace).

1: https://www.his-conference.co.uk/session/visiumcore-a-high-i...

Garmin do one called Varia

RevK's blog has a lot of interesting posts on it.

https://www.revk.uk/

He also runs an excellent ISP in the UK called AAISP which I can highly recommend (https://www.aa.net.uk)

AAISP build their own core & customer networking devices/routers from scratch (not Linux based) in the UK. They are fascinating to use - a completely different evolutionary tree to any other networking kit I've used. Some unique features.

https://www.firebrick.co.uk/fb9000/

I'm sorry you've had a bad experience but I don't agree, I prefer it to the ST, TI and definitely the Microchip tooling. It's CLI first, like the Espressif and Pico tooling which is a big plus for some and not for others.

Also, no mandatory login walls for toolchains and datasheets gets them a lot of goodwill in my book.

The TinyCurrent or uCurrent can be used for this as well when paired with a scope with scpi. However, the ranges aren't dynamic which is annoying if you're using something a WiFi part where you're going from uA to 200mA.

https://n-fuse.co/devices/tinyCurrent-precision-low-Current-...

They also made a manual expresso machine, although I don't know if they continued production after the initial kickstarter run.

https://www.chronova-engineering.co.uk/epoch

In the New Forest national park in the UK (where there are about 5000 free roaming ponies) they've been fitting them with reflective/hi-viz collars for years. Makes them much easier to see at night in winter.

https://www.hlsnewforest.org.uk/2024/10/24/reflective-collar...

It's obviously way too late now but esphome is a very nice easy mode solution for the whole remote upload/logging/server/mqtt/iot widget thing if you don't want to drag in esp-idf. First time bootstrap is via serial/webusb and then it's all OTA.

You can write custom c++ modules for bits they don't have already, although that's pretty rare. Often used with HA but it works fine standalone with MQTT too, and deployment doesn't have to be from a server.

https://esphome.io/

If it's a 13, there's a couple linked from here: https://wiki.archlinux.org/title/Framework_Laptop_13_(AMD_Ry...

I use the "cab404" one and very impressed with it.

Better if you need to send it to Mars and fly it there, otherwise yes which is why these designs aren't particularly widespread.

They can't patent the coaxial helicopter UAV bit because there's a huge amount of prior art.

Contraction of donkey's years, a common en-GB idiom for a long time. Good reference though!

Definitely not a new form factor, this has been around for donkeys. I've personally seen them for at least 20 years at various industry shows.

This is presumably a totally uncritical lazy press release copy paste. For goodness sake, NASA's Ingenuity is not exactly a secret and that's only the latest in a very long line of commercial coaxial UAS.

Looks like a perfectly nice coax, but exactly the same tradeoffs of much higher mechanical complexity for a slightly smaller operating footprint which make them less appealing for most use cases. The article completely glosses over the fact that most traditional X/+ designs fold for transport.

Have both, the Pine Time hardware is impressive for the price and props to the creators of the various available operating systems that are surprisingly capable, stable and super hackable.

Pluses of my Pebble Time:

- A lovely always on e-ink screen (the Pine Time has a TFT that relies on wrist detect to be visible, like an apple or pixel watch)

- Much better battery life

- A perfectly crafted UX full of lovely little touches, it's hard to explain if you haven't used one. It's full of animations but somehow they aren't annoying. Bit like using BB10. You can tell the dev-years & care that went into knocking off all the rough edges. It's the opposite feeling of "f you you're the product" I get from using most modern "tech" (Windows/Pixel watch/etc etc).

- Brilliant timeline view

- Rock solid connectivity (again, better than android/pixel watches)

- Much nicer HW feel in terms of build & fit/finish

- Huge user base who created a massive range of apps & watch faces

- Hey here is our new laser printer

- You can't print from Office you need to export to a PDF

- Then use our SecurePrintTM application to send your PDF to the printer. It uses a hard coded mTLS key to talk to our cloud so it's super safe.

- Also SecurePrintTM sends all your PDFs through our servers where we could read them because we control all the keys. We promise we won't though. Don't worry, they are mTLS encrypted on the way to our cloud!

I do understand your point - the current implementation of LAN mode would not be suitable for enabling on a network with very high security requirements. I just don't understand how Bambu think this improves things.

Why not add user controlled OAuth/mTLS to the X1E? Hell, make it additional paid extra. Right now, it seems like their new approach is worse for everyone.

If MQTT is fundamentally insecure, someone needs to inform the AWS IoT and Azure IoT teams.

While they are at it, they need to change their user admin consoles to only allow access via mTLS rather than sending "plain text" passwords over HTTPS as part of their OAuth 2.0 logins.

Yes, hyperbole, but there are many threat models and mTLS isn't some magic panacea, there are tough issues around key deployment and management which Bambu obviously haven't thought through.

https://docs.aws.amazon.com/iot/latest/developerguide/mqtt.h...

Just like HTTP, there will always be someone who manages to misconfigure or turn off all the security. That doesn't make the protocol bad or irrelevant.

The majority of deployed MTLS certificates I've seen in the wild are used in IoT contexts to auth against MQTT servers because of the many advantages MQTT has over HTTPS for that use case.

I wasn't aware of any specific vulnerabilities in the basic MQTT design (assuming it's over TLS).

I agree that MTLS for embedded m2m/IOT auth against MQTT is pretty standard (see AWS IOT, Azure etc) but do paper printers used in enterprise which have displays typically require MTLS for printing?

Surely any corporation with a security team would VLAN and null route these things anyway - only the enterprise targeted X1E model has an ethernet port, all the others are WiFi only.

Does anyone know or can see an actual concrete security concern with the current implementation of LAN mode?

https://github.com/Doridian/OpenBambuAPI/blob/main/mqtt.md

Right now, the printer's local MQTT server can only be accessed from the local IP using an 8 digit password obtained through through the physical display.

I can't personally see any fundamental issue with this design assuming the implementation is correct, but I'm curious if others can.

https://blog.benjojo.co.uk/post/sn2010-linux-hacking-switchd... if you hadn't seen it already and the associated HN comments:

https://news.ycombinator.com/item?id=40141967

I'm interested what others think of their existing design and whether there are any fundamental security issues that will be resolved by their proposed change.

They are proposing requiring a secret signed certificate to carry out any actions beyond monitoring for both the cloud and local (on printer) MQTT servers. These certificates would be issued at the discretion of Bambu by their CSR, currently only for "Bambu Studio" their slicer, Bambu Handy (their mobile app) and "Bambu Connect" which will enable upload G-Code generated by third party slicer (a workaround for existing functionality being removed). This "secret" certificate has already been extracted from the Bambu Connect application as per the article as their new security model requires embedded this certificate into desktop applications.

The current design:

https://github.com/Doridian/OpenBambuAPI/blob/main/mqtt.md

Connecting to their cloud MQTT requires a username and token already. These details are obtained via a HTTPS request to their login server using your bambu account (which requires a valid email & possibly captcha) to obtain a token. The cloud MQTT is TLS secured, although this is just to encrypt the traffic (aka HTTPS), it is not mutual authentication.

Connecting to the MQTT server hosted on the printer (aka LAN mode) requires a fixed username and a local access token (a random 8 digit number). This can be found via the physical display of the printer in a menu (or apparently cloud MQTT!?). This access token can be refreshed via a menu option again physically at the printer. To be clear, this token only allows to you connect directly to the local MQTT server running on the IP address of the printer, so in most environments this should only be the local network. This is also the password for the FTP server that can be used to upload/download sliced 3mf/gcode files.

Personally - this design seems ok to me? With an MQTT service properly configured to isolate user accounts from each other, this is a pattern widely deployed for embedded devices (Azure IoT, AWS IoT etc).

I don't see how the "DDOS" related issues they are claiming would be related to this specific design. If the issue is in the login server - well, that's prior to authentication anyway so nothing they are doing here will fix that.

If it's problems with your cloud MQTT service not being properly isolated - maybe fix that? If the DDOS is at L2, auth isn't going to help. You require logins tied to an email, you can block clients that misbehave once they are logged in.

Nobody is brute forcing the local MQTT server via XSS or something, because JS doesn't allow for raw TCP connections. Are they concerned about malicious software already on the network? Then rate limiting on the printer side or switch to a random length alphanum LAN token to increase keyspace.

I'm curious what more qualified people think, I cannot see any justications for their proposed design improving security. So either;

a) They've decided they are incapable of properly securing their MQTT cloud stuff and instead of fixing that just want to assume every client connected to their cloud MQTT servers is fully trusted. I'm sure that'll work great. Doesn't justify adding this to the local MQTT servers on the printers - if anything that reduces security, as to roll certificates you now have a long tail of printer firmware updates.

b) It's not about security

It's an anglicized version of a town in Wales:

https://en.wikipedia.org/wiki/Caernarfon

Part 2 goes into the methodology - it's some neat analysis!

http://www.statsmapsnpix.com/2023/04/the-longest-line-part-2...

You could use ws28xx/skxx based addressible strips laid out in rows. Usually WLED would be recommended to drive it, but for playing a video, the teensy fastled library comes with a demo specifically doing what you discuss with a film.

https://quinled.info/2019/06/03/what-digital-5v-12v-rgbw-led... good intro to the subject.

The athom stuff is a bit annoying because they never bothered to upstream anything to support their fairly minor changes - they just forked instead. You can still install upstream WLED, but the remote control support is faffy.

The mottramlabs or QuinLED boards don't have this problem.

Mandatory cloud connection for the initial setup (although you can use it in LAN mode afterwards).

WT32-ETH01 about $7 on Aliexpress if you want something ESP32 based. As easy or easier to get started with than the STM parts in my opinion. Comes with MQTT, HTTP clients & servers etc.

When I last used Cube-MX, it was a very unpleasant experience throughout. I'd use stm32-hal or libopencm3 out of preference if I was using the parts again. The tool itself and the code it spat out had all sorts of nasty bugs and edge cases that cost days of debugging. Maybe it's improved since.

https://github.com/egnor/wt32-eth01

Now that I think about it, it's pretty shocking if a trainer doesn't support FTMS - did you check if it does? Possibly they are programming the Microchip BLE gateway to implement the necessary FTMS characteristics and using the UART bit for talking to the app.