Rick's b.log - 2022/06/26
It is the 21st of November 2024 You are 52.15.68.97, pleased to meet you!

Rick's NetRadio v0.10

I have had it installed for a while, but there were various teething problems as the app developed. Perhaps due in part to my use of ESP32 rather than an actual Arduino? However these problems have been resolved, and I tried once more to see if I could do something with the software.

After a tedious copy-paste process, as the app didn't want to open my NetRadio.ino file but was happy with the exact same data pasted into a new version (weird...), I started up the compilation.

The compiler took a long time to build... everything. I'm starting to see why the PC version is lethargic. Eventually it completed.

So, time to give it a better workout. This time I was going to make a few small modifications and then try an upload to the ESP32...from my phone!

It was, shall we say, a little challenging to write code on a phone. I would imagine it would be a lot better with a Bluetooth keyboard. Additionally, it would be good to turn off the line numbers and get rid of the banner saying what the file is. It's not a big deal in the screenshot to the right but it's a huge amount of space when using the phone horizontally.
Plus, the ability to make the text smaller would be great. Not to mention "list of functions" with the ability to jump to one. But, hey, these things are sure to come in time. As it is, it's a quirky but capable development environment.

To my mind, even though a lot of stuff was being rebuilt over and over, it did seem as if the compilation worked faster in subsequent runs. Indeed, when I screwed up and forgot an opening quote, the compilation aborted with the expected error after about three minutes. For the Arduino IDE on my PC, it's waaaay longer.

I made the following changes:

• Updated the radio stations to remove the ones that either no longer exist, or require https. Unfortunately the first two new stations don't work (Eagle 80s - keeps redirecting; epic rock radio - fails). They work fine with CustomRadioPlayer on my phone, so not sure quite what's up there.
• Serial port flushing prior to line input. It seems that serial terminals on my phone, when editing the station, skip right over the station name (it works on RISC OS), so I added buffer flushing to toss any stray data. I have not tested this, however.
• When in line input, pressing ^U (that's ASCII 21, or 15 hex, if your serial terminal has a macro mode but no control keys, like most Android ones) should erase the entire line of input. I have not tested this either.
  Note that, on Android, it seems that serial terminals do not offer a real terminal emulation, so instead of backspacing properly, you'll see a lot of ^H. Also, many of them are line-interactive, in that you enter a line of text and tap a button to send it, meaning that deleting anything is problematic (hence the ^U above).
• A long-standing issue is that if a station was failing to connect, you would have to time pressing the buttons just right to be able to switch to a different station. This was Nintendo Hard (verging on Damn Near Impossible).
  Now, if a station is trying to connect, pressing either button at all will invoke a station change. The button check happens between the connection failing and the artificial delay (so you can see the message on the LCD). Just press the button and hold until there's a change, it'll only take a moment.

These are all fairly simple changes, easy enough to do on a mobile device.

I plugged the NetRadio into the Xiaomi Mi 10T using an OTG adaptor, and it fired up, sort of. The LCD was quite dim, I don't think the phone was spitting out as much juice as the power brick. But it worked. I could see status in the serial monitor.

I tapped the Compile button, and it was done by the time I came back with a nice cup of tea.
I then tapped the Upload button and had a brief panic in that I had no paperclip handy to prod the BOOT button on the ESP32 board. As it turns out, Arduino Studio is completely okay with that. The board booted straight into upload mode. The data was transferred, and the board was then rebooted. All automatically, the way it should be. The way the PC is completely unable to manage.

And... well... that was it. No tears. No sweary-sweary. No blood sacrifices. No reaching for the pickaxe.

It. Just. Worked.

Which is a damn sight more than I got out of the Arduino IDE on my XP box.

Here is the update as a binary. You'll need to Google how to use esptool in order to update your device.

If you are wondering why there's no source release for this version, it's because I'm just a little bit miffed that some people have made some useful enhancements (somebody added SD card support for those boards with a little µSD holder onboard), and when I ask if they can provide the source, it's radio silence.
This project has been licenced EUPL, a proper open source licence, with the unwritten implication that if others provide useful extensions, then these will be made available in order that I can incorporate such changes into my master copy. End result? Something better for everybody.

To date, I have received some thanks, which is always appreciated. But not one single line of source, or bugfix, or anything.

The changes I have listed above are pretty simple to make. But if you don't feel up to it, email me for the latest source.

As for Android Studio, it did its job. It did it well. It did it better than the official Arduino IDE. There are issues, but I think most of those are down to a phone not exactly being an ideal device on which to write code. That said, persisting is worthwhile given that everything else is a nicer result. Maybe it won't seem so great if you have a modern PC? My 2.8GHz Pentium 4 box running XP is easily owned by Arduino Studio running on a Xiaomi Mi 10T, a sort of middle-range smartphone.

Arduino Studio is on Play Store, but note that it might require a device running in 64 bit mode, which means if you have some el-cheapo device it might not be suitable. That said, a device slower than a Pi3 or Pi4 mightn't be the best tool for developping.... well.... anything, to be honest. ☺

But if you have a decent smartphone, and a tonne of space for installing a board environment (the ESP32 stuff takes about a gigabyte), then it's well worth a look.

Take me to your larder, I'll see your leader later

Anyway, as good as Android Studio is, Google Sheets is the complete opposite.

Sure, the Sheets app works as a simple and quick way to edit data in a spreadsheet, but that's about all that it is capable of doing. If you want to print in such a way that it doesn't try to squeeze everything on to a page making unreadable text, but instead print only those columns in use, you'd be best deleting the unused columns. There's no way of ignoring them or printing a selection.
Turning gridlines on and off? Website, not app. Setting up custom colouring for various events? Website, not app. Given the website needs to be run in desktop mode, or it'll try to throw you into the app, you'd have thought that the app would at least be nice and capable. You'd have thought.

Anyway, what started out as an exercise in getting a shelf installed to tidy up the kitchen has turned into dual shelves (amusingly, the exact same thing only purchased about ten years apart!) and a reasonably well stocked larder... if you like cereal and pasta. ☺

My larder.

I also have a printout of the larder contents with a bunch of blank squares at the bottom, so I can update the paper in realtime, and periodically sync the spreadsheet. It's less annoying doing it that way.

It would appear that the Chrome browser has a few unofficial and undocumented hooks into Android itself. Why do I say this? Simple. There are certain actions that one can perform on a spreadsheet in the desktop website version that cause Chrome to crap itself messily. One such action that is 100% repeatable for me is to enter a cell range to select a range of cells (A1:G157), then opening the File menu and tapping Print. It does not work with a selected range. Interestingly, tapping the print button does.

Chrome will clear to a blank white screen. Once in a while it might briefly flash black. Your phone will be mostly unresponsive, you'll need to firmly prod the home button part of the screen to get out of Chrome, but if you do it wrongly, you'll get this:

Hang on, isn't it Chrome that's crashed?

As we all know, other apps crash. Firefox falls over from time to time. So does QuickEdit. The usual result is that these apps just vanish. They don't freeze the entire device, hold it to ransom, and make the OS think that something entirely else has dropped dead. So I can only surmise that Chrome has tentacles where they shouldn't be.
This ought to be a worry, given the lack of sensible content blocking within Chrome.

And finally...

A visit to Asia for lunch.

Your comments:

Zerosquare, 26th June 2022, 21:38

I'm surprised you seem to like Picard's "asian" recipes. I've tasted a few of them, and to me they range from "meh" to "🤢". They certainly share very little with the real dishes they're named after.

Rick, 26th June 2022, 21:53

I'm British. It's a country known for stealing everybody else's cuisine, and then doing it wrongly. 😉    I used to know an Indian woman who ran a small convenience store. After getting to know me, she invited me around back for some chicken tikka. The only thing it had in common with what I knew as chicken tikka (from an Indian restaurant, no less!) was the name. She told me that foreigners owning restaurants and takeaways "Englishify" the food until it is something the locals will actually eat, which typically bears little resemblance to the same meal as would be served in the country of origin.    So, it's probably 🤢 if you've eaten the real thing. If not, Picard's offerings beat poisonous burgers!

J.G.Harston, 27th June 2022, 01:41

"so I can update the paper in realtime, and periodically sync the spreadsheet"    Bingo! This is exactly what I recommend for any sort of data collection system.

David Pilling, 27th June 2022, 13:57

Slow builds with Arduino are a common problem for me. Happens on visual studio code too - any change and it rebuilds everything. Diversity of systems or do developers just have much faster hardware.  If I had the time or I was going to do lots of work I would revert back to calling the compiler from the command line - make files and all that.

Rick, 27th June 2022, 14:40

Looking at the output of my app, it looks like the problem is that the ino file *and* all of its dependencies (all the included libraries) are built fresh in a temp directory. Once the binary has been created, the temp stuff can be discarded.  It would be far better to have a .o directory alongside the ino source, to keep things that haven't changed. But.... :/

graham toal, 1st July 2022, 21:39

richard, check the facebook acorn group ... i posted the source of acorn teletext and some related code. i would link here but currently on a cell phone. email me if you need more detail.