The day we tried to talk to a Raspberry Pi

Uncategorized
1

The Day We Tried to Talk to a Raspberry Pi

The job sounded simple.

I had a Raspberry Pi 4.

I had a computer.

I wanted the computer to talk to the Raspberry Pi.

That was it.

People apparently do this every day.

The first suspect was the SD card. Windows could tell there was a 32 GB card in the machine, but wouldn’t give the bloody thing a name or a drive letter. We tried another adapter. And another. A little 4 GB card worked. The 32 GB card didn’t.

Eventually I gave up.

Another day.

Then I bought a decent new Verbatim 32 GB card. Premium. 90 MB/s. 600×. Surely that would put an end to the nonsense.

Windows saw it.

Verbatim SD (G:)

Beauty.

Raspberry Pi Imager started writing. Slowly, because somewhere between the computer, the reader and the card was a speed bump, but it was writing.

Then verifying.

Then:

Verified.

Into the Pi it went.

Red light. Green flashing.

Then the red light started flashing too.

Apparently that was bad.

Out came the power supply. In went a 5 V power bank.

Solid red. Flashing green.

Right. One bastard identified.

Now we had to find the Pi on the network.

raspberrypi.local?

No.

arp -a?

That showed us some numbers.

There was 192.168.0.35.

There was 192.168.0.40.

We pinged .40.

Four replies. Beautiful.

We tried SSH.

Connection refused.

Perhaps SSH wasn’t enabled.

Before doing anything drastic, we put .40 into Firefox.

A printer status page appeared.

We had successfully established communications with the printer.

Fine.

On to .35.

Ping worked.

Firefox found nothing.

That looked promising.

SSH?

Connection refused.

We eventually switched the Raspberry Pi completely off, cleared the network table and discovered .35 was still there.

So .35 wasn’t the Pi either.

Much later the router would reveal that .35 was a Chromecast.

At this point we had attempted to SSH into both a printer and a Chromecast.

The Raspberry Pi remained unmolested.

Perhaps I had entered the Wi-Fi password incorrectly. Perhaps I hadn’t enabled SSH. Perhaps Raspberry Pi Connect was involved. Perhaps the SD card was crook.

Back to Raspberry Pi Imager.

Access denied.

And again.

Access denied.

Now Windows wouldn’t recognise the card.

The built-in card reader looked suspicious. The portable reader looked suspicious. The card looked suspicious. Frankly, everyone in the room looked suspicious.

I went to the laptop in the shed.

The portable reader happily read a 4 GB card.

It happily read another larger card.

The 32 GB card?

No.

Then it did.

And it was empty.

Back at the main PC we started pulling the problem apart instead of merely swearing at it.

Device Manager could see the USB reader.

Disk Management could see the 4 GB card.

Healthy FAT32.

But no drive letter.

We gave it one.

There it was.

Then I worked out another little piece of Windows wisdom: after telling Windows to safely remove the card reader, don’t just pull the SD card out and stick another one in. Pull the whole USB reader, change the card, then reconnect the reader.

Another bastard identified.

The 32 GB Verbatim appeared again.

Disk 8.

29 GB.

Was it write protected?

DiskPart said:

Current Read-only State: No
Read-only: No

Could Windows actually write to it?

We created a file.

Inside it we wrote:

Doonie was here.

Closed it.

Opened it again.

Doonie was still there.

The card was fine.

The reader was fine.

Windows could write to it.

So why couldn’t Raspberry Pi Imager?

Because Imager wasn’t trying to write a little file to G:. It wanted control of the entire physical disk, partitions and all, and Windows wasn’t giving it that control.

So we went back into DiskPart.

Very carefully:

list disk

Disk 8 — 29 GB.

Definitely the Verbatim.

select disk 8

Then the command with teeth:

clean

Done.

The old partition structure disappeared.

Back to Raspberry Pi Imager.

Writing.

There was the bastard.

It wrote.

It verified.

We put the newly written card into the Pi.

Now came the original job, which by this stage seemed to have occurred sometime during the reign of Queen Victoria:

Talk to the Raspberry Pi.

Why, I asked, couldn’t we just plug the bloody thing into the PC?

Fair question.

We found an Ethernet cable. White, with yellow ends. It plugged into the Pi, which seemed sufficient evidence that it was probably an Ethernet cable.

There was no spare Ethernet socket on the PC.

Then another thought:

Why not temporarily unplug the PC from the internet and use that socket?

So we did.

Which also disconnected ChatGPT.

Fortunately I had a phone.

PC directly connected to Pi.

Ethernet light on.

Excellent.

Windows gave itself:

169.254.167.234

The Pi remained elusive.

So we abandoned that particular rabbit hole, restored the PC’s internet connection, and plugged the Pi into a spare LAN socket on the router instead.

Now the router itself could tell us what was connected.

And there it was.

Magnifiser-2

Wired Ethernet.

192.168.0.179

And while we were there, the router finally solved one of the day’s mysteries:

192.168.0.35 — Chromecast.

We had indeed been trying to SSH into the Chromecast.

Back to Command Prompt.

This time:

ssh doonie@192.168.0.179

And instead of:

Connection refused

we got:

The authenticity of host ‘192.168.0.179’ can’t be established.

That was the most beautiful warning message I had seen all day.

I typed:

yes

It asked for the password.

I entered it.

And after a day involving two SD cards, several readers, a dodgy power supply, Windows drive letters, Device Manager, Disk Management, DiskPart, Wi-Fi, SSH, ARP tables, Ethernet cables, a printer, a Chromecast and one strategically deployed file containing the words Doonie was here, the computer finally said:

doonie@Magnifiser:~ $

That little dollar sign was the whole bloody point.

My PC was talking to the Raspberry Pi.

The Raspberry Pi was talking back.

And somewhere on the network, a printer and a Chromecast were probably wondering what the hell had just happened.

2

Hi Geoffrey
So much for “working out of the box”
You much have some patience. I think I would given up at about half way through that.

Reading some of these posts I have come to the conclusion that pretty much nothing in the RPi inventory has any backward compatibility at all. When you change something you seem to need to change or juggle everything down to even the operating system to get some sort of combination that does what you expect, even if only badly.

Some of this could be attributed to inexperience and/or lack of knowledge but hey! This is supposed to be hobby and maker stuff so it should not be too unreasonable to expect a product to do what the marketing blurb says. Should it ??
Cheers Bob

3

Correct, but to be frank I thrive on the challenge.

4

Today’s Magnifiser adventure.

The plan was simple enough: get the old laptop talking to the Raspberry Pi so it can eventually become the control console for the Magnifiser.

First problem: the laptop is Windows 7, 32-bit.

No Python.

Modern Python won’t run on it, so we went hunting backwards and found Python 3.8.9, 32-bit. Then the download on the old laptop failed.

At this point the human out-thought the AI.

“Can I download it here and move it to there?”

Well, yes. Of course you bloody can.

USB stick. Sneakernet. Python installed.

The command prompt couldn’t find python, but py worked, so we stopped fixing things that weren’t actually broken.

Next I copied the Magnifiser control software across, opened a command prompt directly in its folder and ran:

py laptop_control.py

Up came the Magnifiser control panel.

Clicked TEST CONNECTION.

Magnifiser connected.

So we now have:

Old Windows 7 laptop → network → Raspberry Pi

working.

The camera itself is still out in the shed, so we sensibly declined to test a camera that wasn’t actually connected.

With about half an hour left, we decided to make the Pi camera-control service start automatically at boot. This involved PuTTY, nano, systemd, three black windows, one non-blinking green cursor and eventually neither the human nor the AI being entirely certain which bloody command prompt was which.

We got the service file written and saved — nano reported “Wrote 13 lines” — but the final enable command came back “command not found.”

At that point the clock won.

So I packed it up.

Current score:

Laptop talks to Pi: YES.
Magnifiser control program runs on 32-bit Windows 7: YES.
Pi automatic startup: NOT YET.
Human sneakernet: undefeated.

Next episode: find out why systemd told us to bugger off.

5

Excellent write-up — the printer and Chromecast detour made me laugh. The router’s DHCP lease list is usually the quickest way to identify a Pi once it is on Ethernet, especially when mDNS is not responding. For a repeat setup, Raspberry Pi Imager’s customisation options can preconfigure the hostname, user, SSH and network settings, which avoids having to discover and enable SSH after the first boot.

1 Like
6

Awesome thank you. The project is ongoing.

7

Report — Connecting the Ryzen and L430 for File Sharing

18 September 2026

Objective

Establish a simple file-transfer system between the Ryzen desktop in the house and the Lenovo L430 intended for the Magnifiser, so files can be transferred without USB sticks, email, or carrying the laptop backwards and forwards.

The desired end result was deliberately simple:

Put a file into SHARE on one computer → collect it from the other computer.

SHARE is to be a transfer tray, not permanent storage.

What we started with

Both computers were connected to the Telstra home Wi-Fi.

The Ryzen’s network address was established as:

192.168.0.166

The first test from the L430 to the Ryzen failed. However, both machines could successfully ping the router at 192.168.0.1, proving that each had a working network connection.

We then discovered that Windows Firewall on the Ryzen had its File and Printer Sharing echo-request rule disabled. After enabling it for the private network, the L430 successfully pinged the Ryzen:

4 packets sent, 4 received, 0 lost.

That proved basic L430 → network → Ryzen communication.

Creating the share

A folder was created on the Ryzen:

C:\Share

Windows sharing was enabled for that folder and Everyone was added.

The network path shown by Windows was:

\\DESKTOP-J3JMFG2\Share

We also used the Ryzen’s IP address during troubleshooting:

\\192.168.0.166\Share

The bastardry

Although the L430 could reach the Ryzen, Windows refused access to the share.

The useful error was:

Account restrictions are preventing this user from signing on.

This led us into Windows authentication.

During repeated attempts, Windows temporarily locked the account for 30 minutes. net accounts confirmed both the lockout duration and observation window were 30 minutes, so we stopped hammering it and let the lockout expire.

We subsequently established that the normal Ryzen account was named:

Doony

—not Doonie, which had caused some confusion during troubleshooting.

We checked both layers of permissions on C:\Share.

The share permissions already allowed Everyone access.

The NTFS Security permissions, however, initially allowed Everyone only:

  • Read & execute
  • List folder contents
  • Read

We enabled Modify, which consequently provided write permission as well. This was necessary for SHARE to become a genuine two-way transfer tray.

Dedicated sharing account

Rather than interfere further with the normal Doony Windows login, we created a separate local account specifically for networking:

shareuser

It was given its own password, with Password never expires selected.

shareuser was then explicitly added to the Security permissions for C:\Share and granted Modify permission.

This gave us a clean separation:

Doony = Geoffrey’s normal Ryzen account

shareuser = network file-sharing account

Making the connection

From Command Prompt on the L430 we mapped the Ryzen share as drive Z: using the Ryzen’s IP address and the dedicated shareuser credentials.

After a fair bit of wrestling with Windows command syntax, the important result finally appeared:

The command completed successfully.

In File Explorer on the L430, under This PC → Network locations, a new item appeared:

Share

It behaved much like another drive or USB stick.

The final proof

A small test text document was created in C:\Share on the Ryzen.

Initially the L430 reported that its mapped Share connection had disconnected. Investigation showed that this wasn’t another Windows-sharing problem at all:

the L430 had simply dropped off Wi-Fi.

The network icon showed it was disconnected.

After reconnecting the L430 to Wi-Fi, we opened Share again.

The test file created on the Ryzen was there.

Result

SUCCESS.

We have now demonstrated the complete chain:

Ryzen → C:\Share → home network → L430 → mapped Share

The L430 can reach the Ryzen, authenticate independently using shareuser, and see a real file placed into the shared folder.

We also configured the folder for read/write, so it is intended to work in both directions.

Operating rule

The agreed philosophy is:

SHARE IS A TRANSFER TRAY, NOT STORAGE.

A file placed there is waiting to be collected. At the destination computer it should normally be moved to its proper home rather than endlessly copied, preventing the eventual plague of:

thing.txt
thing (1).txt
thing (2).txt
thing-final.txt
thing-FINAL-final-bloody-final.txt

We also decided that eventually SHARE should have an obvious desktop shortcut on both computers, so using it requires no knowledge of IP addresses, network paths, drive mappings or any of the Windows entrails we had to crawl through today.

Bottom line

What sounds like the trivial task of “make two computers share a file” required us to diagnose networking, firewall behaviour, Windows sharing, account restrictions, lockout policy, user names, share permissions, NTFS permissions, credentials, drive mapping and finally an unrelated Wi-Fi dropout.

And then we beat the bastard.

Today’s target was to prove file sharing. It is proven.