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.
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.
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.
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.
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.
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
- 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.
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.
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.