Very well done! When adding a chord on a key, I'm missing a small preview of the chords as they appear in the autocomplete list, or would be nice to be able to assemble a chord on a fretboard view. What made you start work on this app? And what is the logic behind how the chords are laid out on the keyboard?
On the outside it looks very similar to what Michael Levin found on electrical communication between living cells. There too, the organism's cells were able to structure and repair their larger-scale morphology: https://www.youtube.com/watch?v=XheAMrS8Q1c
Great read, thanks for sharing this. I'm also coming from software and have recently started making some hardware for personal use in my free time. The idea of selling it as an actual product has occurred to me, but the thought of dealing with all the logistics quickly makes me reconsider. Congrats on your launch!
It's not limited to WiFi networks and indeed the fingerprints you suggest would be a lot better because they would change significantly over time. The whole WiFi networks idea kinda stuck because it's an obvious an easy thing to grab from the environment using a mobile phone. An audio fingerprint would definitely be doable on mobile.
I see, this sheds some new light on your initial concerns. I'm aware an attacker can keep pretending to be inside an environment once they've seen it. I wasn't accounting for a scenario where an attacker has a huge database for queries like coords -> list of wifi networks. I was under the assumption services like Wigle only provided the reverse lookup (wifi -> coords). Indeed an attacker could potentially reverse the LSH tags if it hashed the wifi environment within very small geofences. It's bit of a needle & haystack problem but not an impossible one with enough resources. I wouldn't say it's a perfect system and I don't mind it falling apart under scrutiny, I just found it an interesting idea so I really appreciate you thinking along here.
Edit: Maybe some preshared group hash (kinda beats the point), or combining multiple modalities (eg bluetooth, shared interests) or some kind of proof of work token could help mitigate some of these issues. I guess anything to reduce the time to attack helps in this case? Or anything that really pins down environment + time, like what smath described in his comment. In essence, the core idea of minhash + lsh works and it doesn't limit you to just wifi networks. The key is being able to grab a fingerprint that is unique enough and different enough each epoch. Wifi networks are just easy enough to grab vs something more low level like an APs beacon timing interval jitter or something.
Thanks for the feedback! Rainbow tables probably won't work here since the epoch (rounded to 5 minutes) salts everything, so precomputed tables would expire constantly. You would use use BSSIDs + SSID in real implementations. The MinHash part creates 128 hash values from the entire observed set, not a subset of 3, then LSH divides these into bands where similar sets collide probabilistically based on Jaccard similarity. I've tested with two phones where one saw 3-4 networks and the other saw ~10. They still found each other, and you can try it in the interactive demo yourself. You're right it's not entirely privacy preserving, really depends on your threat model as I discuss in the security section. Your idea about combining area hints with time-based salts is interesting though, feels like it could bridge geospatial indexing with this approach! The whole geospatial indexing thing was something I became aware of late in the project and didn't go into further. It's probably a much simpler approach if geolocation is important. In the current approach, geolocation doesn't matter at all, only 'the environment', whatever that may be.
My immediate thought after seeing the first chart was that it is inversely related to my own experience with movies in the last 20 years. Maybe there's an idea in there for a 'score normalizing' browser extension.
OnStepX is very much pulse based as far as I understand it. I haven't encountered offloading techniques like you mentioned yet. Since both motors support (multiturn) positon modes, it should be possible to completely forego the pulsebased approach and only drive the motors using regular (and less frequent in comparison to pulses) position instructions over CANBUS. I spent some time reading the code in OnStepX to understand how to implement it in this way but hooking it up in pulsemode was just too easy to get started.
Indeed the cost is mainly from assembly. The board itself is 2 layers, all default settings at Jlcpcb except for the color which is now black as opposed to the default green. This increases the cost of the board a bit. You can experiment with their calculator to find out more. I've ordered 5x each version, which is also the minimal order amount. I did try to stick to the standard library as much as possible but it's not easy once you go beyond standard passive components. Can't currently tell the exact difference it would made if I had soldered the THT by myself, likely not enough for me to bother. You could be right on that last part. The details on it are not as fresh in my head anymore. It is definitely true that you want to minimize the amount of different components. If you need 4k and 6k resistors you're better off buying 2x2k and 3x2k instead.
Yes! And when you need advice on an electronic circuit you can export it in netlist format from KiCAD. This is a textbased representation of the schematic which is very understandable by LLMs
Thanks for the compliment and links! Can you tell me more about the aircraft tracking? I've been toying with the idea of being able to select a nearby airplane on flightradar24 and instructing the mount to follow it as it comes into view. Not sure how I would even begin building that.
Yeah I didn't expect such a stark difference in image quality from the same lens when using it for day photography vs astrophotography. Just goes to show how incredible a proper astrograph is. I'm located in Belgium: high light pollution and very humid skies. The only targets worth bothering here are close to zenith. It's a fun rabbit hole to be in :)
Thanks, glad you enjoyed this. It's good to be in a place where you're confident things will turn out alright when you send your designs halfway across the world to be manufactured. I've so far only had positive experiences with JLCPCB, especially with issues that turn up during their review process. I forgot to add a fillet around the edge where the DEC axis sticks out of the tube and they sent me a quick message to say "We can't guarantee a 100% right angle here cause of the minimum radius of our bits". I assumed they would just gloss over this and manufacture it anyway, but they gave me a chance to review it just in case it was important to the design (it wasn't in this case, but still). On the PCB side, I used a plugin for KiCAD that automatically generates the production files and the bom.csv - It's really critical to review this when you load it into their tool because the automatic recognition/matching with components sometimes has mistakes in it.
Thanks! If you hook your ZWO up to Kstars/EKOS you can use plate-solving in software to find out exactly where your scope is pointed at and then adjust accordingly.
Cool project. What prompted you to write this? Asking because EKOS already has pretty good scheduling features (I've seen, not used). Along the way I did vibe-code a TUI for controlling the INDI server running on the MeLE 4C minicomputer attached to the telescope: https://www.svendewaerhert.com/content/blog/telescope-mount/... - I switched to a headless setup using a remote indi server after having a bad experience with reliability using remote desktop in Gnome. I'll probably put this TUI on Github once I clean it up a bit.
Haha, the thought of using OpenSCAD briefly crossed my mind when I found out about it but I didn't want this project to take a year extra to complete. I do consider exploring some of the other CAD alternatives though if budget permits.
Not sure what you mean with complex mechanism. The mount has a similar architecture to other commercially available mounts like the HEM15 iPolar for example.
I switch between the cheap Byomic 76/700 newton and my Sigma 600mm lens (Canon EF but using an adapter to fit the Olympus body). I tried to get the DSLR looking into the newtonian but it was just too heavy, causing the plastic focuser to simply bend way off axis. I've since bought a dedicated astro camera (Neptune C II) which fits alright on the newtonian. I'm keeping the Byomic 76 only for visual observations now. Looking to buy a proper refractor of around 480mm. The Sigma 600 does alright with the DSLR but isn't very sharp, hard to focus and suffering from some coma. It's good enough to learn the ropes for now.
Short answer: it's in the same ballpark as other mounts of the same size. The theoretical accuracy for RA is 0.198″ (65,536 steps and 100:1 reduction) and for DEC is 0.253″ (256*200 steps, 100:1). In practice many things will reduce this accuracy: seeing, proper polar alignment, sturdiness of the wedge and tripod all account for some loss in accuracy. My highest achieved accuracy was probably around 1″ during brief moments, I'm sure with excellent seeing this could reach <1″ performance.
I estimate a load capacity of 8-10kg. It's not designed for the really big equipment cause I also would like to take it on camping trips. If I were to do this again I will definitely add a threaded hole to mount a counterweight bar. I've noticed the tracking accuracy drop slightly when the mount is in the most overhanging positions.
Checking the datasheet is essential, they usually show the “must-have” parts around a chip. Beyond that, good habits are adding decoupling caps close to the pins, keeping ground solid, and following the reference layout. I also learned a lot just by listening to experienced designers explain their choices, like here: https://www.youtube.com/watch?v=aVUqaB0IMh4
Sounds like a really interesting potential project. I've been pondering a system that would make amateur observations usable beyond pretty pictures. Single frames captured could be shared in raw form along with metadata (time, coords, calibration frames), potentially allowing aggregators to process it for scientific research (or even prettier pictures). The Vera C. Rubin Observatory is now able to capture the entire southern hemisphere in a couple of days. Imagine having our capturing software contributing to a planet-wide crowdsourced telescope array.