Friday 21 October 2022

Structured Data in Scrutiny Scans

Back in April we launched version 12 of Scrutiny (skipping 11). 

Since then the topic of structured data has been raised by users. 

Scrutiny has long collected Twitter and open graph meta data, and has displayed those fields in its SEO > Meta Data table. But not structured data provided via json-ld. 

It's easy to collect this but not so easy to display it en masse as it has a 'tree' structure.

Here are some first steps. I'm open to discussion on where to go from here. The following is all possible with the current version of Scrutiny, 12.5.0

The json-ld is collected from each page and parsed. Perhaps the most important pieces of information are the @types. Like headings there may be multiple, and at different levels, so like headings they can be displayed in the table, in a single column using a separator and in the order that they appear.

The column can be switched on using the Columns selector above the SEO > Meta Data table


That allows you to see at a glance what pages have the structured data and what type(s) are used.

For more detail on a particular page, a double click in this table opens the Page Inspector:


This is the Meta data > json-ld tab of the Page Inspector. Note that we're not seeing the original json string from the page. It has been parsed and formatted. It's the way that a machine would read it, and if Scrutiny can't read the json, then there will be an error message here. (You can see that I've used @graph here in order to display both the software application and the breadcrumb list  within the same chunk of json-ld. If there are multiple chunks of json-ld on the page then they'll be amalgamated here.)

Also in the same inspector is a Twitter Card viewer. This will display information from the Twitter meta data if present, and fall back on Open Graph (og:) fields, as Twitter does. This doesn't look exactly the way that Twitter would display the information - Twitter also draws on info from the Twitter account referenced.




Thursday 28 July 2022

Milestone for MIDISID

 

MIDISID has two SID chips (modern SID replacements, SwinSID Nanos) driven by a Pi Pico. It has MIDI in and audio out.

I'd hoped that this version of the boards (above) would be the final 'release' version. There are some very minor tweaks to make but I'll be building 5 of these - one for myself and four for people interested in an 'earlybird' deal. I'll try a black version too.

The firmware has taken many many hours, and it's clear that there will always be new features on the horizon. If it sells then I look forward to the ongoing development.

It's working very well, see the video below, in which it is in 'General MIDI' mode, I'm playing in the MIDI files for the DOOM levels. 



Saturday 9 July 2022

Picoterm v1.1 released, choice of colours and Turbo Pascal 3

A user reported that when using Turbo Pascal 3 on his RC2014, scrolling within the source code editor wasn't working.

My way of investigating issues with escape codes is to load up a modified version of PicoTerm which prints every character as a number. I also had the RC2014 connected to a terminal on my Mac, so I could still use TP3.

Investigating these numbers showed that the scroll up / scroll down (and also the scrolls that happen when you cursor to the top or bottom of the window) all rely on two escape codes that PicoTerm didn't support:

<esc>[1L

and

<esc>[1M

These are not listed on the Wikipedia ANSI escape code page, which has been my main reference. PicoTerm didn't support them before today. (And neither did PiGFX as far as I can see.) But they do work within minicom and Teraterm, so it seems that they're reasonably 'standard'.

It appears that these codes mean 'insert a line at the cursor position, scrolling everything down'  and 'delete a line at the cursor position, scrolling everything up'.  I have assumed that the number is the number of lines to scroll, although I can't be sure about this until I find some documentation.

Picoterm is built with scrolling in mind - each line of text is a structure, and the display buffer is an array of pointers to these structures, so scrolling is no more than switching 30 pointers around, and clearing a line.

So adding support for these escape codes was straightforward. Each is a variation on the scroll that is already used when the cursor reaches the bottom of the screen.

Here is a quick demo, first showing another new feature of the textmode (mono) version of PicoTerm - the ability to switch colour on startup, according to button A, B or C being held on power-up. White, Green or Amber. 

Then a quick demo of the scrolling up and down within Turbo Pascal 3's editor.

More information about PicoTerm generally, and downloads, are here.


Tuesday 21 June 2022

Clock, temperature and humidity display using Badger2040

 The Badger2040 is a RP2040 with e-ink display. Or possibly an e-ink display with a RP2040 on the back:

It has other goodies like 2Mb of flash ram, some buttons and lots of connectors such as a battery connector, stemma/qwiic socket and breakout pads for various serial connections. And USB-C for programming and serial in/out.


I've added an Adafruit temperature / humitity sensor using the stemma connector. This particular sensor is AHT20. The only negative thing about that for this project is that it has a fixed i2c address, and I would have liked to hook up two, one for indoor and one for outdoor temperature. I'll have to buy another which is a different type and has a different address.

For now my program is reading the data from the one sensor and displaying the temp and humidity. This took me some time because the libraries for this sensor (that I could find) were either circuit python or arduino.  If you want to use either of those things, you only need to write a couple of lines of code. For C (or in this case C++)  I had to write my own code starting with i2c_write_blocking() and i2c_read_blocking() and referring to the AHT20 data sheet and the Arduino library. An annoying bug (on my part) meant that I spent more hours than I should have on that.

With that done it was a breeze to print the stuff to the screen (using the Badger C++ example code). I wrote the clock from scratch using the time.h functions within the Pi Pico C SDK to access and process the hardware timer - get_absolute_time(), to_ms_since_boot() etc.  I've got the up and down buttons adjusting the hours or minutes up or down, with buttons A and B switching between adjusting hours and minutes. 

It looks great. The e-ink display is very easy to read in any light and uses no power, except when updating.  I've got the screen updating every 30s or if you push a button to adjust the time.  Another curious thing about this type of display is that it keeps displaying its contents even with power disconnected. Meaning if you wear it as an actual badge, you don't need to power it once it's displaying what you want!

The battery pack that comes with the Badger is a bit chunky (two AAAs inside). I don't know how long that lasts, but I might use a small lithium battery instead, that can be stowed more easily on the back.

UPDATE

I've now got it running off my first found-free-in-the-street  battery. This is a relatively small one compared to the 500+ mAh ones Big Clive has been finding but it is nice and flat and it has been powering another pico project of mine and showed no signs of flagging. I'll be fascinated to see how long it runs the Badger!

Another improvement I've made today is to make the clock periodically write some details to the flash memory, so that if power is removed, it'll start up displaying the same time as it did when disconnected. That saves a lot of button-pressing after a battery change.

I've been struggling with writing to the flash memory on the Pico and on this device, but today I solved my issue. Basically don't have USB stdio enabled while trying to write to the flash.







Monday 25 April 2022

Milestone for Scrutiny - v12

Last year we spent many months rewriting our website crawling engine, the reasons are here. 

Since then, Integrity went through a beta period and eventually Integrity, Integrity Plus and Pro version 12 were released. 

There have been many updates, those apps are becoming mature, the problems found are now increasingly obscure. 

As well as fixing issues with the new Integrity, Scrutiny has been catching up. 

It's now based on Integrity. That approach comes with some compromises (see notes below) but the benefits for all of us are great. 

It also means a totally different interface. Or rather reverting, because up until version 4 Scrutiny had the open, tabbed Integrity-like interface. The move away from that wasn't popular and Scrutiny's UI has been its weak point. 


Notes: (also in the release notes within the .dmg)

There will be no autosaved data for a site until you've run a scan. Your previous scans will only be visible in the previous version. V12 requires new scans before autosaved data is available. This is due to the format of some of the data changing a little, 

V12 isn't document-based. This is part of consolidating Scrutiny & Integrity. Being document-based requires a different architecture within the app, introduces the need for all sorts of complexity and workarounds. The compromise is that it's no longer possible to run multiple scans at the same time. Until there's a 'queueing' system built into Scrutiny 12, you'll need to make sure that any scheduled scans don't overlap time-wise. 

V12 doesn't have monitoring or orphan check.  I don't think either of these features will be missed, and if there is a call for the monitoring functionality, it should be in a separate app. 

The layout is different. I should say 'reverted' because until version 4, Scrutiny shared the Integrity-style interface, and the move away from that wasn't popular. Scrutiny's UI for managing websites hasn't been very user-friendly and had come in for some criticism. It also made it impossible for Voiceover to work (requires visible tabs).

Automatic ftp of sitemaps is no longer available. Scrutiny saves the xml sitemap, you must transfer it yourself.  ftp and ftp+SSL (ftps) has been fine but sftp (which in my experience is now more common) has been problematic

French localisation is unfortunately no longer available. I'm grateful to French-speaking paying customers and people who have offered to help with the translation. The problem isn't paying for translation, but the fact that any new feature or change to the interface (which are happening all the time) requires an interaction with the translator and I prefer a much more agile process. The apps haven't been noticeably more popular in French-speaking countries than without the localisation.


Thursday 21 April 2022

Having got so far with the MIDI SID project, I had this real mess of wires and boards. Then I started to add to the carnage with knobs and a display.  

The problem was that if something stopped working I couldn't be sure whether it was because I'd got something wrong, or had just jogged a connection.

Happily, prototype boards are so cheap that you can order something without worrying about the cost. This isn't even really a prototype yet, not all of the components are on the board. I just wanted the Pico, two SIDs (in this case swinsids) and the MIDI in circuit soldered firmly in place so that I could experiment with knobs, buttons and displays, and develop the software without fear of breaking it by jogging the desk!



To get you up-to-date if you haven't seen my ramblings about this, I'd love a box with MIDI input, SID chips inside, audio out, and simple controls. I'd like to be able to play a .mid file into it, or plug in a keyboard, with options for polyphonic or monophonic output. (I've done some of this using a C64 and MIDI cartridge, but it'll be good to have a standalone box.)  I'd like to try a larger version with enough SIDs to be able to map each midi channel to a voice. Maybe in time I could add the components needed to support real SIDs, but being able to use ARMSIDs would be good as they're a great replacement. (I'm not sure that it's ethical to encourage anyone to use precious real SIDs in something like this.

Quick demo of the thing working (just one channel in, one voice playing). I've got Logic Pro playing a simple tune, with a USB-MIDI converter allowing me to plug that into this board. 

If you're interested in the project, I'm going to use the hashtag #MIDISID on Twitter. 

Sunday 6 March 2022

Minstrel the 4th is a modern recreation of the Jupiter Ace, a lesser-known home computer from 1982. It's notable for its use of Forth rather than BASIC which was common at the time.

The Ace had a ZX Spectrum-like rubber keyboard. The Minstrel's is an improvement but its small tactile switches don't really allow for fast typing.

The Minstrel and similar computer scan the keyboard by reading a group of hardware ports which correspond with half-rows of the keyboard. They expose the bus as an expansion port, so it's possible to intercept those port reads. Here's my working prototype, it uses quite a bit of logic. The Pico's main job is to act as a USB host and allow a modern keyboard to be plugged into its own micro-USB port. and maps the keypresses it receives to the appropriate rows and columns of the Minstrel's keyboard matrix.

It's not only the size and arrangement of the keys that limit typing speed, but the fact that the keyboard matrix is scanned every 1/50th second and then not buffered. So even with modern key switches, this makes typing on computers like the Ace, ZX81 and Spectrum is a bit of a plod. It's easy for the Pico to buffer the keyboard input, and present it to the Minstrel one key at a time, at a speed that it can handle.

This also opens up the possibility of connecting a serial terminal to the device to allow listings to be pasted to the Minstrel. It also means that anything you type using a USB keyboard can be echoed to the terminal giving you a paper tape of  In the top picture you can see that the finished product has a USB-FTDI adaptor attached for this purpose.

My interface is now in production in small batches, please contact me for details.