Tinkering with electronics
thanassis.space
thanassis.space
If you burn a transistor you burn a transistor - it's now useless for its original purpose, so you have to triple check everything.
Also there are 2nd and 3rd order effects that require experience to catch.
Example: I was really happy that my two 555 timers driving some LEDs were synchronized so good until I realized that they were plugged into the same weak power source, so the voltage drop from power surges triggered them both.
Building software is amazing as the barrier is very low and you can iterate and experiment so fast. But 99% of software I've built exists only as 1s and 0s on a hard drive somewhere.
There's something great about physically holding something you've built. I mainly built midi controllers for friends and other weird i/o devices, But the fact that (maybe) they are sitting somewhere collecting dust brings me joy.
My previous job involved lots of lab work, soldering, debugging PCB issues, working with optical fibres, et al. Current job pays better and is complex enough, but it's just me sitting behind a screen all day remotely controlling a piece of hardware we just bought from someone else.
I highly recommend everyone who's into software or design but never did anything with hardware to spend some time this week building a simple blinking LED project with the Arduino
I second that. These days it's very easy to get some hobby projects going in no time and with a very low budget. Arduinos, FPGAs, simple PCB design, it will give you satisfaction and you'll definitely learn lots useful stuff in the process that's not necessarily tangentially related to software
Yet I still tinker with electronics outside of the "real hardware work". It just is fun. Especially if you can teach it to others; or give them the everlasting tinkering bug!
So now anything that I do that has to have an effect in the real world is put together with the absolute minimum in interface hardware and the remainder is software.
Same here. You can build virtually anything in software.
The point I was sarcastically making was that even in SDRs you still have a downconversion via either Direct Converting or SuperHet to baseband so your signals are in the right frequency reference that you don't completely saturate your DSP/FPGA/CPU.
I love software as much as anyone else but just saying that you can do everything in SW is a bit disingenuous.
I wrote "So now anything that I do that has to have an effect in the real world is put together with the absolute minimum in interface hardware and the remainder is software." and the other person wrote "virtually".
Hardly.
Power usage in SW(or FPGA) vs ASIC is easily an order of magnitude difference. For most battery based solutions software based signal processing is right out.
Latency is another, your CPU is going to introduce both jitter and long latency compared to a discrete software solution.
Software also can't handle raw speeds involved in a lot of things. There's not a single CPU out there that can natively handle 5GHz wifi off of the wire. That's why even direction conversion SDRs use a frequency mixer to lower the data rate down to something a DSP can handle.
If you imagine we’re talking about someone’s hobby prototype projects, designing all of those things you mentioned takes skill, experimentation, time, parts, assembly, likely a team collaboration, etc. The combinations of parts get conceptually complicated and the feedback loops during the development process get slower and slower.
Obviously there are reasons to use custom-designed hardware if you are a corporation and you are building a million identical devices, or if you have extreme bandwidth or latency needs that a modern CPU literally can’t keep up with, etc.
But that’s a very different context than what the people several posts up are talking about.
P.S. if you pile your posts with abbreviations your readers have a harder time figuring out what you are talking about.
It doesn't share much, if anything with serial software and you use the same tools(VHDL/Verilog/etc) as ASIC design.
Or power, plenty of battery powered things in the hobby space where using discrete hardware optimized for low power usage is necessary. Discrete hardware doesn't have to be an ASIC, it's still possible to string together a opamps and other SMD parts pretty easily these days.
I still like electronics, but software has spoiled me.
Maybe because of the association that "software = free".
Or because hardware is 3d while software is always 2d. Would you get the same appreciation if you made a piece of hardware that connects to a monitor and shows a blinking dot?
https://partofthething.com/thoughts/making-a-cheap-and-simpl...
Then go for motor control: Servos, steppers, DC motors, relays, solenoids, h-bridges, PWM, etc.
Add in some other sensors - perhaps ultrasonic distance sensing, Sharp IR sensors...
...then move into hacking on a Neato Lidar sensor...
At this point - build a robot?
Probably a hardware object strikes more senses than a software for being something you can touch, but also feel the loss of it if it breaks, because you can't copy it just like lines of code.
This might be something to think about when teaching programming to kids as well. Making an Arduino "do" something still involves programming, but with more tactile results and lower expectations for how much it has to resemble a professionally written app.
Consider checking out an ARM Cortex-M board - you can get an STM32F103 'blue pill'[1] with 20KB RAM, 64KB flash, external oscillators, and a 72MHz clock speed for $5. Plus, it has lots of extra peripherals like a realtime clock which can run off of backup power and periodically wake the chip up from sleep.
The future of embedded development is so bright, you gotta walk around with sunglasses on.
I've also heard good things about NXP's Cortex-M chips - apparently they let you map peripherals to whatever pins you want, which sounds neat. And TI's MSP432 chips apparently have fantastically low power consumption for their performance. Atmel's SAM chips look less promising, with minimal peripherals besides a weird common communication bus that seems to handle things like I2C/SPI/etc, if I'm reading the datasheets right.
Does that sound right? It'd be nice to learn about all of them, but there are only so many hours in a day.
If you still want to use Arduino, I'd highly recommend going for Arduino clones from China. You should be aware that the USB chip is different so you may have driver issues, but I haven't had any issues on Linux. You can get an Uno clone for ~$3.
It's also worth considering moving to the Atmega by itself You can get the chip used in the Uno for $2, set it up on a breadboard, program it with an Arduino as the ISP, still use arduino libs if you want, and eventually move to a custom PCB.
They are way more capable, and they actually cost less than ~$3 each for a simple QFP48 STM32F103 or STM32F051 board, and the smaller chips start around $0.75 for my PCBs.
I was mostly thinking about alternatives for people who are currently using Arduino and want to keep the same toolchain, libraries, etc. but at a lower cost. If someone is comfortable moving outside the Atmega ecosystem, I would recommend ARM chips as well.
Arduino port is just wrapper around stdperiph HAL...
Having a small device with WiFi makes it a lot easier to do interesting things - such as pulling data via Web-based APIs, and submitting readings of sensors to MQ, etc.
Having a "real computer", like a PI, or a blue-pill is nice, but suddenly there is a lot more to think about.
Because I can't justify learning the nitty-gritty of some proprietary 'Tensilica' core. Lately I've been meaning to look into using NRF24L01 transceivers for wireless communications in projects, since breakouts for them are less than $1 each and have the same footprint as an ESP-01 module.
I totally agree with this sentiment, but I would add: I know a guy who designs hardware for a living, and he gets a huge kick from of writing a little Python script. The thrill is mostly in developing fledgeling skills far from your main wheelhouse.
This is an AVR-based pong video game (Grant Searle), modified to work with BBC micro:bits as digital paddles - also operatable from phones via Bluetooth!
This is for a STEM/Code Club event at a local school, for a bit of retro-meets-contemporary fun, and a paddle programming challenge - let's try using the micro:bit accelerometers.
The breadboarded circuit will be made up on stripboard, but I'll take along the prototype.
I got an Arduino recently and it’s the best £6 I’ve spent in ages. My pet project is building a synth driven from the midi output of my keyboard.
As a software person, “real” electronics felt hard to grok. The Arduino has been a dream. You have to learn loads along the way. How do I get audio out? Oh right, what’s PWM? Oh ok, how do these timer things work? But it’s soooo satisfying.
Highly recommended!
It's not to hard to build and not a bad place to start. The code could be better, some variables are poorly named and has some minor bugs (off-by-one on the wave table lookup?). I did start to clean it up but never got to submitting a pull request before moving onto other projects.
People like that design. Others have built more of them. Someone in Australia plans to manufacture a hundred or so. There's enough interest for hobbyists to build it, but not enough for a real production run.
[1] https://github.com/John-Nagle/ttyloopdriver (USB interface for old Teletype machines, models from 1910 to 1960).
(Okay, that equipment is also kinda expensive, and retains its value far longer than old computers... But even new stuff has gotten a lot cheaper than it used to be.)
Maybe half the time that code evolves into an API/HAL that the final application will use. Many times it also becomes code for manufacturing test (burn in with the test code, then reflash with final production firmware right before boxing)
Starting out with application code on top of a brand new design will lead to madness. Take it in smaller steps.
I just couldn't get it to work. While trying to understand what was going on, I literally went down the levels of abstraction until I was measuring voltages with an oscilloscope. Turns out that one of the resistors on the board wasn't properly soldered.
It was a good journey from software to all the way down to hardware, but frustrating. Nowadays I develop web applications and I'm happy that I don't have to deal with this kind of problem anymore.
But I have a hard time generating good ideas. Any thoughts?
UPDATE: I miss remembered, we used the high impedance electrometer to buffer the input of a National Instruments interface board so we could record the voltage build up across the storage capacitors, if you use a normal voltmeter the caps just discarge into the voltmeter and the charge never builds up enough to allow the micro controller to turn on, run the code it needs to and then go back to sleep. You land up with some really nice sawtooth wave forms with this method and, as the acceleration on the vibrational energy harvester increases, the frequency of the sawtooth changes proportionally up to a point where the system is transmitting all the time.
I haven't added solar, as these are inside, near power, but have some solar panels and hardware waiting for me to deploy out in the field (literally). so far, it's been my lack of good waterproof enclosures that has slowed me down. I wonder if there'd be a good opportunity for someone in that space.
One of my favorite companies to work with in this area is Polycase.
The traps are spread around the countryside in dense bush/jungle.
When one goes off, someone needs to tramp in and clear and reset it. Currently, there is no monitoring of any kind, so checking traps is extremely labour intensive.
The trickiest aspect of this project is that each node needs to spend virtually all of its time asleep to minimise battery drain, yet for two nodes in the mesh to communicate, they both need to be awake at the same time. Drifting clocks etc.
The easiest aspect is that the acceptable data rate is 1 bit every 8 hours or so!
LORA doesn't handle any of the mesh behaviour, I'm doing all of that using LORA just at the send and receive level. The devices I am using are moteinos - a cool arduino lora mashup https://lowpowerlab.com/guide/moteino/.
I see various ranges from LORA, the environment is steep valleys and dense bush which severely dials back the range, sometimes down to a few hundred meters or even less. At this stage I haven't played around with optimising the LORA settings, but there are bound to be some wins there since the required data rate is so low.
Good question about installs, my current plan is that before setting out, the user places that part of the network where they are heading into constant beacon mode. The node can then be installed, knowing there's another node within reach.
In practice this should be fine anyway, as the recommended placement for traps for e.g. stoats is every 100 meters or so, so usually there will be other traps within range.
The ATtiny85 costs around $1 - it's amazing what you can do with it. I've made / adapted quite a few projects from there and other blogs
Mini-box has a number of dc-dc converters and battery charging systems for gel-cell and other batteries. I do not have personal experience with their products, but I'd try them first if I wanted something other than a hack.
For hacks there are tons of boost converter boards on eBay/aliexpress, but these typically don't have chargers, short protection, or other features you might want if you need more robustness
Fit your gel cell with an auto accessory socket, then plug in the power supply.