AmazonDynamoDBException: Consistent reads are not supported on global secondary indexes

If you try to execute a DynamoDB query against a Global Secondary Index, by default you’ll get this error:

AmazonDynamoDBException: Consistent reads are not supported on global secondary indexes (Service: AmazonDynamoDBv2; Status Code: 400; Error Code: ValidationException

To avoid this, per answers on this question, you need to call:

.withConsistentRead(false);

on your query expression.

Although the docs here suggest queries are eventually consistent by default, apparently with the DynamoDB mapping api you still need to explicitly set the consisten read = false parameter.

Windows 11, the TPM2.0 requirement and Asus AMD chipset motherboards

Microsoft officially announced Windows 11 today. There was the usual online comparisons between the announced features and other comparable features in MacOS and Linux, like the centered Task Bar that now looks suspiciously like how MacOS’s Dock has looked for, well, years.

In the tech requirements though, there is an unusual detail – Windows 11 requires a motherboard security module called TPM 2.0. Most new motherboard apparently come with one of these, but Asus has produced a number of motherboards in the last couple of years and chose not to include one of these modules onboard. If you run the compatibility checker on a PC with one of these mobos, you’ll get this notification that your PC, that you most likely bought as recent as within the last couple of years, is not compatible with Windows 11:

Understandably, there’s a number of threads online where people are rather upset that the new PC they bought within the last few months is not compatible with Windows 11.

The good news is some AMD Ryzen chipsets have BIOS that includes embedded TPM 2.0 support, even if it’s not provided by a discrete module on the motherboard. On my Asus X570 Plus motherboard it has an fTPM option in the BIOS settings with two options, ‘discrete’ or ‘firmware’. On mine the default option was ‘discrete’ but changing it to ‘firmware’ added the support that the compatibility checker is looking for:

And now running the checker again, everything is good:

ISS SSTV decodes 6/23/21

Highest elevation on this pass was 50 degrees at 12:36PT. It’s interesting seeing the decodes getting progressively better as the signal strength increases towards the highest point, and then dies out again:

12:12PT

12:34PT

12:38PT

12:43PT

ISS SSTV decodes – 6/21/21

The ISS is transmitting SSTV on 145.800MHz this week, June 21-26. I left my laptop running during the day and here’s the decodes I captured. Equipment is an Icom 880h with a homebrew copper wire quarterwave groundplane, and I’m running the RX-SSTV software.

12:32 PT – the highest elevation on this pass was only 22 degrees at 12:34 PT:

12:36 PT:

12:41 PT:

Next pass, 14:09 PT – highest elevation 50 degrees at 14:11 PT:

14:12 PT – probably the best ISS SSTV decode I’ve got so far! :

15:48 PT – there were no ISS passes at this time today, so not sure what this one was: