|
|
|
addicted to exposing the laboratory floor
Sunday, March 7 2021
My brother Don called this morning to tell me he'd received Underbug, the new book about termites and how great it was. He then probably bombarded me with a series of factoids without bothering to note whether I could understand what he was saying. Since getting his flip phone, Don has impressed himself with his ability to remember phone numbers, which is (ironically) a skill that cellphones has made unnecessary. But Don doesn't know how to add to his contact list and doesn't see a need to, given how great his memory has proved to be. Knowing that Gretchen's phone number at the bookstore was easy to remember, I had Don surprise Gretchen by calling her there today while she as on her shift there to tell her how happy Underbug had made him. But that was a mistake; Don ended up calling her twice at the bookstore. She was nice to him on his first call, but by the second she had to cut things short. She often is so busy in the bookstore that she barely has time to eat or use the bathroom, and there was no wasy she could patiently "emm hmm" her way through Don presenting a garbled lecture on the subject of termites.
The other day I managed to put all my loose wall warts and laptop power supplies away, all neatly organized according to specifications. The largest container held all my 12 volt DC adapters, followed close-behind by a collection of 5 volt DC adapters. Then there was my collection of conventional laptop power bricks, then my unconventional brick-like power supplies (including one that produce 220 volts), then my 8 to 11 volt DC wall warts, then my 3 volt DC wall warts, then my six to seven point five volt DC wall warts, and finally my high-voltage DC wall warts. Finally, in a small two-quart container all by themselves, are the AC wall warts. I'll never plug a DC device into one of those by mistake ever again!
The laptop power supplies had been spread out in the middle of the laboratory floor for at least a year, and getting those put away exposed about five square feet of laboratory floor. Exposing floor is an addictive process, and today and I managed to expose even more floor by reorganizing the top of a metal wire shelf as well as some high storage under the ceiling ridge above the doorway to the teevee room. I finally decided to part with a pair of non-working Socket-7 (that is, Pentium-era) motherboards and one of the Samsung 204B monitors with an ugly black line running vertically through the screen. This opened up space in deep storage for the box containing first two iterations of the digital part of solar panel's solar controller, including the socket for a first-generation Atmega8-based Arduino with its analog display (which would show a series of values using a mechanical voltage meter). I'm sentimetal and like to hold on to such milestones in my electronics expertise, though I know from experience that deep storage is the best place for such junk, whereas valuable shelf space visible every time I walk past it is best used for things I'm working on these days, such as Raspberry-Pi-based mechanical robots.
Back in July, I'd had plans to reuse the display from my iMac G4 in some sort of Raspberry-Pi based machine, and I got as far as tearing it all apart. But the fussy business of teasing the wires out of the tiny proprietary connector and hooking them up to a DVI cable proved too daunting, especially since the resolution of the display is only 1680 X 1050. In its deconstructed state, it was taking up a lot of space. But once I put it back together (and confirmed it would boot up into whatever flavor of Linux I'd installed on it), I found it fit nicely in deep storage right next to my box of old digital solar electronics. In 2021, an iMac G4 is worth a bit less than a box of decomissioned solar controller electronics.
Earlier today I finally had success with getting my T-beam device to send packets that were received by my "application" on TheThingsNetwork. The key to getting this to work was picking a different "Device EUI." I'd originally picked a not-so-random series of hexadecimal digits, and apparently the whole reason my application wasn't working was that my data was going to somebody else's application with the Device EUI I'd picked. It would've been super helpful had TheThingsNetwork told me that the Device EUI I'd originally chosen had already been taken; that would've pumped hours back into this particular weekend. In any case, with that problem solved, I was now able to test the T-beam at different ranges to see how far it could be from my gateway and still send it GPS positions. It worked okay a couple hundred feet away, but a third of the way down the Farm Road was too far; clearly either the Dragino gateway or the T-beam (or both) has nowhere near the range of those cute little Heltec devices I played with a couple weeks ago.
There's a way to easily show the data coming from my T-beam on a map using a pre-cooked "integration," in this case something called TTN Mapper. But as with everything pre-made, the TTN Mapper was a far cry from vision for an application that maps GPS data. For starters, there are no good map layers to work with. There's a street map, and that's pretty much all you get (in three different versions). There's a radio button for a satellite layer, but that's disabled. And then, as for the data, all that it wants to show is the locations on the map, with color-coded vectors connecting back to the GPS position of the gateway. The only information besides location is signal strength. But if I wanted to use this to show, say, Neville's journey as he carries the T-beam around on his collar, I would want to know the time of each data point, with lines connecting locations according to time. Maybe there is an integration that does what I want a mapper to do, but I have a feeling I am going to have to make my own Google Maps integration. Fortunately, I have done this before and have code I can reuse if I can figure out how to pipe data from my TheThingsNetwork application to a server I control.
In recent years there has been a pattern of me finding pre-built things not quite suited to my demands, forcing me to build my own version of whatever the manufacturered (or otherwise designed) item happens to be. This was true of clock radios, leading to my building of the Ahmed Mohamed clock. My disastisfaction with home weather stations led to me building my own based on a Raspberry Pi Zero. And a year and a half ago I had a thing for replacing the control electronics of remote-controlled vehicles with my own Raspberry-Pi-based controllers.
This evening I somehow managed to blow several hours yet again on my miserable Pycom Lopy board, the tiny board I blew several hours just searching for (and repeatedly overlooking) about a week and a half ago. The problem today was just getting the board to do something and trying to get my mind around how the stupid little thing is supposed to work. I understand the concept of uploading software to boards or flashing media and installing it. With most Python-based microntrollers, you plug them in to your computer, where they appear as if they are thumb drive, and then you copy your software over to them that way. With the Pycom stuff, though, all you seem to get is something called the REPL, which behaves like the text-based environment of a classic 1980s 8-bit computer. You type in commands, and they're executed right away. You can also type in programs, and as long as the indentation is right, they too can execute (though Python has a huge problem in that the indentation of something copied from a web page is almost always wrong once pasted into a REPL). With just the REPL, it's difficult to understand how one creates permanent programs in the device's file system, which it will have to have in order to boot up and start doing stuff. This is where the Pycom documentation completely sucks. Nowhere do they explain what paradigm their devices exist in and how that differs from more familiar paradigms. That's the sort of thing that should be explained right at the beginning, well before they start telling you what pins to hook a USB-to-serial adapter to. This evening all I managed to do was flash a new copy of the firmware, which seems to do things completely differently from how things were done the last time I played with my Lopy. These days, Pycom expects you to add a plugin to one of your Electron-based text editors (either Atom or Visual Studio) and somehow do your REPL and other things from there. But pymakr (the Pycom plugin) doggedly refused to see my Lopy board, even after I'd confirmed that I'd hooked up the serial adapter correctly.
For linking purposes this article's URL is:
http://asecular.com/blog.php?210307 feedback
previous | next |
