The Shark - E J Pratt

 E. J. Pratt (1882–1964) was a Canadian poet with a sailor’s eye and a theologian’s nerve. Trained for the ministry, he abandoned pulpits for poems, and brought with him a moral seriousness stripped of sentimentality. His work is often nautical, scientific, and unsparingly physical. Pratt writes nature not as metaphorical comfort, but as mechanism—precise, indifferent, and lethal when necessary.

The Shark is one of his cleanest cuts.

The Shark

He seemed to know the harbour,
So leisurely he swam;
His fin,
Like a piece of sheet-iron,
Three-cornered,
And with knife-edge,
Stirred not a bubble
As it moved
With its base-line on the water.

His body was tubular
And tapered
And smoke-blue,
And as he passed the wharf
He turned,
And snapped at a flat-fish
That was dead and floating.
And I saw the flash of a white throat,
And a double row of white teeth,
And eyes of metallic grey,
Hard and narrow and slit.

Then out of the harbour,
With that three-cornered fin
Shearing without a bubble the water
Lithely,
Leisurely,
He swam—
That strange fish,
Tubular, tapered, smoke-blue,
Part vulture, part wolf,
Part neither—for his blood was cold.

 

---

Short notes on The Shark

• No symbolism required.
  The shark is not a stand-in for evil, capitalism, war, or the subconscious. It is a shark. Pratt’s restraint is the point.

• Engineering language.
  “Sheet-iron,” “knife-edge,” “tubular,” “tapered.” This is a poem written with calipers, not adjectives borrowed from romance.

• Motion without drama.
  “Leisurely” is doing heavy work. The menace lies in the absence of urgency.

• Cold blood matters.
  The final line denies moral analogy. “Part vulture, part wolf” is immediately revoked. The shark belongs to neither warm-blooded hunger nor carrion logic.

• Harbour, not open sea.
  This is civilization’s edge. The shark knows it. That’s the quiet unease.

• Modern, not Victorian.
  Early 20th century. Post-Darwin, post-romance. The universe does not explain itself, and Pratt doesn’t ask it to.

---

Raspberry Pi 5 Case - Laser Cut

Creality Falcon 2

# Linux Mint Cinnamon (APT-based)

# Refresh package lists from all configured repositories
sudo apt update

# Verify available Inkscape version in current repos
apt-cache policy inkscape

# Install or upgrade Inkscape
sudo apt install -y inkscape

NOTE ... the fpllowing  is the meat .. we just lost the "bones" ie ... URLs etc ... due comms fail ...

Project purpose

Design and build a simple, robust laser-cut case for a Raspberry Pi 5. The case is intended as a functional enclosure for a Pi used as a long-running system hub (NAS / automation support), not as a decorative or novelty object. Priority is clarity, access, cooling, and ease of modification rather than visual gimmicks.

Machine used

• Creality Falcon 2 laser cutter

Software and tooling

• Inkscape as the primary design and inspection tool

• Vector files (SVG / DXF / AI as supplied)

• Workflow decision: open an existing design in Inkscape, inspect and understand it, make only minimal or later modifications. No redesign at this stage.

Source design selected

• Laser-cut Raspberry Pi acrylic case design sourced from VectorsFile

• Chosen because it is mechanically straightforward, industrial in appearance, and not “fancy for the sake of it”

• Uses flat panels and mechanical fasteners rather than decorative finger-joint excess

Material choice

• Acrylic / Perspex, specified as 0.3 neutral density (ND) tinted acrylic

• Rationale:

  • Cleaner, more “factory” aesthetic than MDF

  • Transparent/tinted material allows visibility of the hardware

Adhesive / assembly method

• Use proper acrylic solvent cement (e.g. acetone-based or commercial acrylic cement) rather than mechanical interference fits

• Decision explicitly made to avoid kerf-critical friction joints; glue is acceptable and preferred for simplicity and reliability

Design and aesthetic considerations (initial, non-binding)

• Case should look mechanical and industrial rather than ornamental

• No etched graphics or decorative patterns at this stage

• Ventilation openings are functional; any shaping should serve airflow first

• ND acrylic provides contrast while still showing internal components

• Size and proportions kept conservative; avoid oversized or ostentatious designs

Concrete decisions made

• Use an existing laser-cut design as a starting point, not a ground-up custom design

• Use Perspex / acrylic instead of MDF

• Use solvent cement instead of friction-fit joints

• Inspect and possibly adjust the design in Inkscape after the Raspberry Pi 5 is set up and measured, not before

• Treat this case as a first, simple laser-cut project before moving on to more complex mechanisms (e.g. iris assemblies for later projects)

Current status

• Design selected

• Material and assembly method decided

• Next step: open the vector files in Inkscape, review dimensions and layout, then park the project until the Pi 5 is fully configured and ready for final fitting

System Rescue Tools - Filezilla / Ventoy and Timeshift

Home Automation Computer Newtork Architecture - Mark's Truck

Exaust Fan Iris Shutters - Laser Cutter

Why Speedtest Lies (and What Your Network Is Actually Doing)

  Version: Bush Mobile Data—Observed in the Wild

---

1. Speedtest is an Advertising Tool, Not a Diagnostic

Speedtest exists to:

• flatter telcos,

• reassure customers,

• keep everyone feeling warm and connected.

It is not designed to reveal network failures.
Its job is to present the best-case number it can wring out of your connection, even if the underlying link is dying like a lizard in the sun.

---

2. It Cheats — By Design

Speedtest stacks the deck:

• Picks an ideal server (close to you, low latency, cooperative).

• Uses parallel TCP streams to inflate throughput.

• Smooths out jitter so the graph looks pretty.

• Retries aggressively to mask packet loss.

This creates the appearance of a stable, high-bandwidth link even when the network is held together with fencing wire and hope.

---

3. Why You See “20 Mbps… 0.1 Mbps… 20 Mbps”

What looks like a square wave isn’t real bandwidth variation.
It’s the cheat system breaking down temporarily.

When the tower chokes:

• routing collapses

• packet loss spikes over 80–90%

• TCP stalls completely

• Speedtest can’t fake it anymore → drops to 0.1 Mbps

When the tower recovers for a moment:

• a handful of packets get through

• Speedtest’s parallel streams kick back in

• the illusion resumes → 20 Mbps!

You’re not seeing performance.
You’re seeing optimistic marketing interspersed with reality.

---

4. The Real Condition of the Network

Your proper tools tell the truth:

ping → catastrophic loss

• 80–100% packets dropped

• regular “destination unreachable”

• no stable path to anywhere

mtr → routing collapses mid-path

• hops flapping

• latency in the thousands of milliseconds

• segments disappearing entirely

iperf3 → no sustained throughput

• can’t negotiate

• can’t maintain a TCP session

• server unreachable most of the time

This is structural failure, not “slow internet.”

---

5. What Speedtest Can’t Admit

If Speedtest were honest, it would show:

“Your connection is unusable.”

But honesty doesn't sell telecom services.

So instead it:

• cherry-picks its best 2 seconds,

• prints a big shiny number,

• and pretends the rest of reality didn’t happen.

---

6. The Bottom Line

Speedtest lies because it's designed to.
It reports potential performance, not actual conditions.

Your tools revealed the truth:

• Massive packet loss

• Routing instability

• Flapping radio layer

• Near-zero usable bandwidth

• A connection that works by coincidence, not design

If a network cannot deliver consistent packets,
it doesn’t matter how fast Speedtest claims you are in theory.

---

7. Field Rule of Thumb

Always trust packet loss and routing behaviour.
Never trust a single-number speed result.

Speedtest is a postcard.
ping, mtr, and iperf3 are the autopsy.

---

Note  :  Yeah, it's a bit like the bloke whose wife never cheats on him, except for when he actually finds her in his bed with the milkman, and then he walks out of the room and she's not cheating on him anymore.

FIELD DIAGNOSTIC — “HONEST LINK TEST

 

MARK’S FIELD DIAGNOSTIC — “HONEST LINK TEST”

Purpose:
Run three real-world tests that expose the true condition of a network link (jitter, loss, routing stability, sustained throughput).
Replaces Speedtest completely.

---

COMMAND BLOCK (copy/paste and run as-is)

# 1. Stability & packet loss (50 probes to Cloudflare)
ping -c 50 1.1.1.1

# 2. Route quality (live traceroute + loss/jitter per hop)
mtr -rw 1.1.1.1

# 3. Sustained throughput test (TCP, real flow)
iperf3 -c iperf.scottlinux.com

---

INTERPRETATION (brief)

1. ping

• 0% loss + tight latency → good link

• Loss > 1% → unstable

• Jitter swings > 30 ms → VPN, STT, games, Zoom all degrade

• “Destination Net Unreachable” → upstream routing failure (tower/backhaul dead)

---

2. mtr

• Shows where packets die.

• Loss at hop 1 = tower or local NAT failure

• Loss at hop 2–3 = backhaul congestion/microwave link fault

• Loss only at far hops = upstream ISP issues

This is the “forensic” tool.

---

3. iperf3

• Tests real, sustained throughput — no cheating, no smoothing.

• Smooth graph → link can carry load

• Bursts/stalls → congestion or jitter

• Disconnects → upstream failure

If iperf3 can’t connect at all → the link isn’t routing.

---

CONCLUSION

This triple test reveals:

• jitter

• packet loss

• route instability

• tower congestion

• backhaul collapse

• VPN viability

• torrent viability

• STT reliability

• true usable bandwidth

Speedtest hides all of these.
This rig exposes them instantly.

 

---------------------------------------------------------------------------------------------------------------

Righto — here’s your compact, portable field-diagnostic script.
Name it whatever you like; I’ll call it netcheck for simplicity.

This gives you:

• one command

• clean output

• no dependencies beyond mtr and iperf3 (install once)

• works anywhere

---

1. The Script (netcheck)

Copy/paste this into a file:

#!/bin/bash

echo "===================================="
echo " Mark's Honest Link Test – netcheck "
echo "===================================="
echo

# ---- 1. PING TEST ----
echo "[1] PING: Stability + Loss"
echo "--------------------------"
ping -c 50 1.1.1.1
echo
echo

# ---- 2. MTR TEST ----
echo "[2] MTR: Route Quality (loss per hop)"
echo "--------------------------------------"
mtr -rw 1.1.1.1
echo
echo

# ---- 3. IPERF3 THROUGHPUT ----
echo "[3] IPERF3: Sustained Throughput Test"
echo "--------------------------------------"
iperf3 -c iperf.scottlinux.com
echo
echo "Done."

---

2. How to install it

Save it somewhere sensible — I’d suggest:

~/bin/netcheck

Then make it executable:

chmod +x ~/bin/netcheck

If ~/bin isn’t already in your PATH, add it by editing ~/.bashrc:

echo 'export PATH="$HOME/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

---

3. How to run it

Anytime, anywhere:

netcheck

That’s it.
No mucking around.
It runs the three honest tests in sequence:

• ping → stability

• mtr → route diagnosis

• iperf3 → sustained usable throughput

You get a complete truth readout of the link without touching Speedtest or any GUI.

---

4. Notes

• If mtr or iperf3 aren’t installed, do this once:

sudo apt install mtr iperf3

• If iperf3’s test server is ever unreachable (rare), swap in Cloudflare’s:

iperf3 -c speedtest.wobcom.de

But the default one is rock solid.

---

If you want a version that logs automatically to a timestamped file for later analysis, I can package that too.

 

BMS scratchpad

MOSFET aplication 

DC to DC Buck COnverter on Order ... October 30 

Good — that’s a clear picture of the long game.
You’re talking about building a real supervisory charger, not just a DC-to-DC patch-cord.

Quick sanity sketch of where you’re heading:

---

1. Core design philosophy

You don’t want a black-box BMS that makes patronising “safety” decisions.
You want transparent logic and override capability — the engineer stays in charge, not some half-translated firmware from Shenzhen.
So your control unit’s job is measurement + decision, not hard-coded vetoes.

---

2. What you already have

• Cell balancer with RS-485 telemetry → gives you per-cell voltage data.

• Panels + buck → reliable, controllable charge source.

• Known operating envelope: 8S LiFePO₄, 24 V nominal, 29 V ceiling.

That’s plenty to start scaffolding a proper BMS/charger around.

---

3. ESP32 reality check

• It does have ADCs (two 12-bit SAR converters), good for up to about 3.3 V input with scaling.
  Not lab-grade, but fine for pack voltage, current-shunt sense, thermistors, etc.

• If you want better resolution or isolation, bolt on an external ADC (ADS1115, INA226, etc.) via I²C or SPI.

• It has Wi-Fi, Bluetooth, UARTs, and can talk to RS-485 modules easily.

• You can easily hang a Coulomb counter IC (e.g., LTC2944 or INA219) on the same bus.

So the ESP32 is absolutely a viable main brain.

---

4. Roadmap (voltage-centric first)

1. Input stage: buck converter limited to ~29 V.

2. Sense stage: measure pack voltage, input voltage, charge current.

3. Logic stage:

   • If V > 28.8 V → disable charge.

   • If V < 26 V → allow charge.

   • (Later) Add temperature sanity and hysteresis.

4. Coulomb counter: zero at 28.7 V, integrate thereafter.

5. Communications: read per-cell data from the balancer via RS-485.

6. Override hooks: manual enable/disable regardless of sensor paranoia.

---

5. Why this makes sense

You’ll end up with a system that:

• Handles LiFePO₄ correctly (no forced float or over-voltage nonsense).

• Lets you decide when “too cold” is too cold.

• Provides telemetry and SOC you can actually trust.

• Costs less than the imported junk you’d be replacing.

---

In short: your instincts are dead on.
Build around the ESP32, keep the buck as a controllable power stage, and use the balancer’s RS-485 feed as your cell-health data.
We’ll get to current sensing and control loops later — for now, your voltage plan is a sound foundation.

AI Assistant.

 chatGPT

whisper

Schumann scope toy

 NOAA ? Online Readl time observatories 

Low Frequency High Gain Amp Raw signal aprox 10 pV ... probbably too low to monitor with afforadable electronics. 

Cardboard as a Building Material

Wheat Pate -  Hydroscopy ? 

Hot Glue and Parafin?

Waterproofing using Shellac. 

A bit of the Old Gainfull

 

Зоя — За грехи

https://youtu.be/vwLuzqoAGNg?si=GFyA2ioPBD2P7PHl

Think of the time we can save and how much more efficient we can be.... 

Diesel Heater.

The Fuel tank used to feed the old petrol generator which was heavy and loud and way too high VA. 

It is 200 x  450 x 600 = 54 litres  2 x 20 litre jerry wont quite fill.

The Heater burn / litres per Hour 1.2 - 2.4 

The fuel sender is 3 Ohms to Negative / Earth when nearly full and also when nearly empty;  so the sender is toast. To get at it I would have to remove the fuel tank which would involve getting under the chasis and removing 4  bolts with nylocks nuts...  easy .. 

Bolts removed and tank is ready to slide.

Will wait till the tank is empty again before recommencing. 

UPDATE : Inspected the sender and it looks fine  - 170 Full  - 3 Empty Ohms

I quite like the look of those old round dials. So if I go say 50 mA and thought of it as litres? 

The diesel heater has been largely trouble free for a few years now. 

It would be nice to engineer it into a IOT system. 

November 2019 Fault

Symptoms:  blows smokey unignited fuel vapour out of the exhaust. Last time this happened I disconnected the fuel and ran it thorough a cuppla start cycles to lean it right out. That was about 4 tanks of 24 liters of fuel ago. It worked.

My initial (wrong) diagnosis was that I had been running it on a low setting. I thought maybe it was running too cool and not de coking the combustion chamber.  I have never run it one any setting but 100 percent since the last failure.

Problem solved. The connector that takes the start up current is not up to the job. Inadequate current gets to the glow plug to start combustion but a credible voltage drop still exists.

Fix:  involved breaking out the conductors to a more robust connector lug / bus style system.

Progress Report: System Check & Load Testing

Progress Report: System Check & Load Testing

Overview

We've done a full diagnostic run on the electrical system, measuring load currents for every major component, troubleshooting power anomalies, and identifying key improvements.

Key Findings:

1. General System Health:

   • System functions as expected, but a few design oversights need correction.
   • Power distribution is uneven, with some unexpected loads running off unintended circuits.

2. Battery & Charging:

   • MPPT Controller Reset Fixed Charging Issue
     • Previously showed zero charging current, but now pulling a healthy 25A.
     • Green LED confirms proper solar charging operation.
   • Battery Load Benchmarking Completed
     • Measured power draw for all major devices, giving us a clear power budget.

3. Load Measurements (All Rounded to Nearest Decimal):

   • Nook + Monitor + Speakers: 1.6A
   • Fridges (Both Running): 4.4A
   • All lights (except overhead workbench ones): 3.8A
   • Water Pumps: Kitchen = 2.2A, Shower = 2.0A (shower pump likely underpowered)
   • Television (Idle, No Signal): 8.6A
   • Projector: 2.0A (estimated from spec sheet)
   • Full System Running (Excluding Pumps): 16.5A
   • Peak Draw (TV + Everything Else On): 22.1A

4. Power Distribution & Wiring Issues:

   • Overhead workbench lights mistakenly wired into the UPS.
     • Fix: Separate UPS loads from general circuits (new dedicated switch panel needed).
   • 13.8V DC-DC Converter Always On.
     • Fix: Investigate why power is leaking past switch.
   • UPS Power Isolation Issue.
     • Fix: Install big-ass diode to prevent reverse current flow from UPS to main system.

5. Solar Array Performance Test:

   • Open Circuit Voltage: 65.5V (expected for system configuration).
   • Current Clamp Test Failed: Not sensitive enough to measure individual panel outputs.
   • Alternative Testing Needed:
     • Option 1: Install switches to isolate solar panel strings for individual testing.
     • Option 2: Install current shunt resistors for accurate millivolt readings (messy, but effective).

6. Water System:

   • Tank Capacity Calculated: ~1,500L
   • Level Indicator Works Well: Meniscus visible in clear tube.
   • Pump Performance:
     • Kitchen pump fine.
     • Shower pump underpowered—may need an upgrade.

Next Steps & Fixes:

• Electrical:

  • Install big diode on UPS power feed.
  • Build dedicated UPS switch panel to separate loads.
  • Investigate why 13.8V converter stays on when switched off.
  • Determine best way to measure individual solar panel current flow.

• Water System:

  • Consider higher capacity pump for shower.
  • Continue monitoring tank usage rates.

• Final System Testing:

  • Conduct a full overnight test to simulate real-world battery usage and check power management.

General Summary:

• System is fundamentally sound, but has inefficiencies.
• Load testing gives a clear picture of power consumption.
• A few wiring mistakes need correction.
• The UPS needs proper isolation to prevent backfeed issues.
• Solar panel current distribution is unknown—we need a better way to check it.
• Shower pump may be too weak.

All in all, good job catching these issues now rather than later. This was a long-overdue professional-level diagnostic, and it’ll pay off big-time in system stability and reliability.

Wildlife Camera Trap.

 High torque Servo

 Adafruit PCA9685 16-Channel Servo Driver

I have received a Rasberry Pi 5 8G and Camera from Core Electronics,

My truck is park inside a Bottlebrush Paperbark tree and the flowers will soon be appearing. A family (soon to be ~fingers crossed~) of Chitty Chitty (Wagtails) are eyeing it off.

there are lots of designs for Pi Based Camera Wildlife traps. They need to have image detection / recognition to be practical.

Pi 5 Wildlife camera

K5528 • Currawong Valve Amplifier - made me an offer I couldnt refuse

https://www.altronics.com.au/p/k5528-currawong-2x10-watt-stereo-valve-amplifier-kit/

Made me an offer I cant remember - cuppla hundred bucks due water damage on the box.  ..

Silicon Chip Online Issue - November 2014 

Silicon Chip Online Issue - December 2014

I buy these to build the speakers with these drivers.  First made in July 22.

 DAEX58FP

 Idea which I considered. A Pi Audio Hat

https://core-electronics.com.au/raspberry-pi-iqaudio-dac-pro-48159.html

Raspberry Pi IQaudio DAC Pro

SKU: CE07563

https://www.max2play.com/en/2016/01/raspberry-pi-zero-with-iqaudio-dac/ https://www.sparkfun.com/products/17738

Decided not to. It is too complicated to get the audio to it. Perhaps .wav files to get proper Hi Fi Audiophile cred? Not worth it. 

 

FAULT : Both channels intermittently becoming quite and distorted. 

When i tried to power the Wi Fi  source from a USB source there was a huge hum so i just temporarily powered it off a battery pack.  This time i should derive the Power from the 12 Volt DC heater line and that way there are no external earths. 

 The audio input needs to be wired to the in/out panel.  

Fixed that and biffed out that horrible bluetooth abomination i had and relpaced it with an automotive one.. Deriving the 12 volt from the heater voltages.

Much Much nicer but these snot green planar "speakers' still sound terrible. And very quiet. 

I have some scrap speakers to test out but probably best I aim to get some twin code old school efficient conventional speakers. They are slightly better bass but still very quiet at full volume.

FAULT : The 330 Ohm 5 watt resistors are cooked. 

I left out a link .. I did put a link on LK4 / 5 which complete the feedback loop presumably can remove them for testing. The links I left out are next to them.

https://www.diyaudio.com/community/threads/silicon-chip-mag-currawong-amp.264057/page-4?utm_source=chatgpt.com