On 09/12/2025 19:14, Rich wrote:

In comp.os.linux.misc The Natural Philosopher <tnp@invalid.invalid> wrote:

On 09/12/2025 11:57, Andy Burns wrote:

The Natural Philosopher wrote:

might be dependent on where I parked the car

Monitoring within the appliance bays of multiple fire stations,
certainly shows signal levels exhibiting high and low levels depending
whether the truck is in or out ...

Umm. Well now the rain has gone and the wind died down a little I am
getting +6dB better signal. I could move the car...

I'll park that one (sic") till I use the car again, then I'll move it ...

Water greatly absorbs 2.4Ghz signals, so it is not surprising you see stronger signals once the extra "water" is no longer in the signal
path.

I knew that theoretically, but it was interesting to see it playing out
in practice...
Also the difference waving foliage made...

--
"What do you think about Gay Marriage?"
"I don't."
"Don't what?"
"Think about Gay Marriage."



--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In comp.os.linux.misc The Natural Philosopher <tnp@invalid.invalid> wrote:

On 09/12/2025 11:57, Andy Burns wrote:

The Natural Philosopher wrote:

might be dependent on where I parked the car

Monitoring within the appliance bays of multiple fire stations,
certainly shows signal levels exhibiting high and low levels depending
whether the truck is in or out ...

Umm. Well now the rain has gone and the wind died down a little I am
getting +6dB better signal. I could move the car...

I'll park that one (sic") till I use the car again, then I'll move it ...

Water greatly absorbs 2.4Ghz signals, so it is not surprising you see
stronger signals once the extra "water" is no longer in the signal
path.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 09/12/2025 11:57, Andy Burns wrote:

The Natural Philosopher wrote:

might be dependent on where I parked the car

Monitoring within the appliance bays of multiple fire stations,
certainly shows signal levels exhibiting high and low levels depending whether the truck is in or out ...

Umm. Well now the rain has gone and the wind died down a little I am
getting +6dB better signal. I could move the car...

I'll park that one (sic") till I use the car again, then I'll move it ...

--
"A point of view can be a dangerous luxury when substituted for insight
and understanding".

Marshall McLuhan



--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

First of all thanks to all those who responded on my first efforts to
put a battery power Pi Pico W outside and have it phone home.

Having eliminated temperature and supply voltage as issues, I delved
into wifi and router logs, and it was clear that it was sometimes
getting a DHCP lease and even occasionally opening a TCP/IP connections
and sending data. And might be dependent on where I parked the car and
the weather.

I tried putting a tin tray behind the router and that made it worse.

Now the layout was that a ground floor router through the window and the garage was not very good at about 30m range.

Then I remembered I had put an Ethernet port in an upstairs bedroom by
the window in case I wanted to use it as an office.

It was further away - 35m or so - but much less cluttered path. It just
had to go through a corner of the garage.

Instantly the router reported about 8-10dB more signal and almost
reliable comms resulted.

Now instead of 1 in 10 connections working,m I have one in ten
connections *not* working.The limit seems to be about -93dBm reported on
the Pi Pico and about -90dBM reported on the router/access point.

What seems to be the key is uncluttered line of sight for as much of the distance as possible. And wind and rain. There are trees /bushes behind
and the last two days have been very wet and very windy. And I have seen
good connections drop without sending data and reported signal levels
up to 10dB worse.

On the plus side for those contemplating similar, the ultrasonic module
seems flawless..

(HC-SR04) and the original one worked down to about 4V. I believe newer
ones will do down to 3.3V.

Also the nano power timers (TPL5110) works OK. Although it needed 100uF
across the output power rails to stop it oscillating :(

The whole thing seems to be accurate to a couple of litres in a 2500
litre tank.

(I spent several hours trying to remember enough high school
trigonometry to work out the area of a chord. )


All in all the reliability of the wireless is about the same as the old commercial (465Mhz) sensor except that that needed the receiver where I
could read it. The luxury of just looking on a web browser makes the
whole thing worth while, as is knowing exactly when the batteries are
running out. So far in about 6 weeks of battery testing the 3 x AAs have
gone from '4.6V' to '4.4V' . Battery replacement does not need the whole
unit to be removed. Simply a battery holder and cover with a simple 2
pin battery plug.

The hassle of setting up the C SDK is worth it as there is much that
Python cannot do.
And I am hoping never ever to have to spend two hours bleeding 60 metres
of partially air filled oil line when the tank runs dry (or is emptied
by thieves)

There are apparently blue tooth solutions that talk to yiur mobile
phone, but once again, the phone needs to be in range...

Anyway thanks to all who helped, and the upshot is that liquid levels
sensing with battery powered ultrasonics and a wifi link is perfectly
doable and depending on circumstance, very worth doing.

And I knew all that trig would come in handy one day :-)


--
No Apple devices were knowingly used in the preparation of this post.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 12/9/25 06:57, Andy Burns wrote:

The Natural Philosopher wrote:

might be dependent on where I parked the car

Monitoring within the appliance bays of multiple fire stations,
certainly shows signal levels exhibiting high and low levels depending whether the truck is in or out ...

Wi-Fi is sometimes just black magic ...

Simply just moving things just a couple of
inches oft makes an unreasonable difference.

2.4 tends to have better range indoors
than 5ghz - making up for the lower xfer
rate by being Reliable.

5G phone can be just as spooky.

6G phone ... I saw somewhere that a theoretical
'dynamic signal steering' tech might help - but
real-world that's still to be seen.

Robots ... with current tech they will depend on
being able to connect their tiny AIs to a BIG AI
somewhere else so they can do much more. BUT, if
6G is horrible, then what ?

If monitoring 'emergency vehicles/installations'
is critical, maybe consider something using lower
frequencies than wi-fi ??? In USA I think there's
a designated comm space in the 400mhz band. It'd
still be good enough for a 1-fps camera feed.

Ah ... POTENTIAL cheap solution. Haven't fooled
with it in about 10 years but I think it's still
possible with Linux. Just buy one of those wi-fi
extender/repeater thingies (about $50 USD) and
put it not far from the main router. Make it
wlan1. At least with wpasupplicant and dhcpcd.conf
you could designate an automatic "fall over" in
case the main signal got crappy. Not 100% sure
what happens now with apps if you list a wlan0 and
wlan1 at the same time - will the app just use
whichever, or both, without complaints ???

Between the two, 'shadow' areas ought to largely
go away.

Pity nobody makes a 5ghz "viewer" so you can
get at least a fuzzy picture of the signal at
different places :-)

I have a repeater to reach an out-building. Gonna
try to add it as wlan1 just to see what happens ...









--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 12/10/25 00:18, Andy Burns wrote:

c186282 wrote:

If monitoring 'emergency vehicles/installations'
   is critical, maybe consider something using lower
   frequencies than wi-fi ???

Nah, it was mostly "for interest" to gather a few more values from kit that's already being monitored. Someone else mentioned water (presumably
as rain) don't forget the fire appliances carry around their own water,
but hopefully it's low down for CoG reasons, while the access points are mounted higher up.

Fair enough.

Now if real, legal, 'security' was an issue
then you'd want a solid connection all of
the time ... and one wi-fi point likely won't
provide that.

Did a very quick look at fail-over network
connections, but almost everything assumes
multiple routers and perhaps iptables
nastiness.

Easiest ... add one wifi extender, log into
the camera, see whether you get more bars
with the main or the extender.


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 12/10/25 00:38, Andy Burns wrote:

c186282 wrote:

   Now if real, legal, 'security' was an issue
   then you'd want a solid connection all of
   the time ... and one wi-fi point likely won't
   provide that.

Only the largest couple of stations have multiple APs in the bay.  The building and individual vehicles have 4G, and the buildings form a
meshed POCSAG network between neighbouring towns (or parts of cities).

Ummm ... an 'extender' is a bit different from
an 'access point' (and cheaper). The extender
binds to the access point/router. Connected
devices may, as needed, connect to the main
point or the address of the extender and still
get net access. Wired equiv is more like a
hub/switch.

I do have experience - like last week - with
extenders. Just got in a cheap spare, had to
set it up (CAN be slightly confusing but not
bad at all). My better extender doubles
the range of my good wifi connection, to
some out-buildings with some IP cams (and
soon a home-built "weather" thing (Pi3 based,
have a couple of spares & some 1-wire sensors)).

Anyway, judging by the problem you claimed, your
easy fix is an extender. Use the main point for
cams/devices at point-blank range and put the
extender across the bay, best higher up. Use
whichever is more reliable for the particular
device in the building.


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 10/12/2025 02:19, c186282 wrote:

If monitoring 'emergency vehicles/installations'
ÿ is critical, maybe consider something using lower
ÿ frequencies than wi-fi ??? In USA I think there's
ÿ a designated comm space in the 400mhz band. It'd
ÿ still be good enough for a 1-fps camera feed.

465Mhz.
Its equally shit really.
I ought to resurrect 27MHz.. that is still free-ish

ÿ Ah ... POTENTIAL cheap solution. Haven't fooled
ÿ with it in about 10 years but I think it's still
ÿ possible with Linux. Just buy one of those wi-fi
ÿ extender/repeater thingies (about $50 USD) and
ÿ put it not far from the main router. Make it
ÿ wlan1. At least with wpasupplicant and dhcpcd.conf
ÿ you could designate an automatic "fall over" in
ÿ case the main signal got crappy. Not 100% sure
ÿ what happens now with apps if you list a wlan0 and
ÿ wlan1 at the same time - will the app just use
ÿ whichever, or both, without complaints ???

Depends how they are set up.

ÿ Between the two, 'shadow' areas ought to largely
ÿ go away.

ÿ Pity nobody makes a 5ghz "viewer" so you can
ÿ get at least a fuzzy picture of the signal at
ÿ different placesÿ ?

Well they do. Its called a smart phone.

If te phone has 5Ghz wifi then a wifi sniffer app shows all.

ÿ I have a repeater to reach an out-building. Gonna
ÿ try to add it as wlan1 just to see what happens ...

--
"First, find out who are the people you can not criticise. They are your oppressors."
- George Orwell


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 10/12/2025 10:29, c186282 wrote:

What we WANT is for a device connection to use
the BEST signal - whether that's the primary
router or an extender - and switch back and
forth automatically depending on the connection
quality. Looks like it CAN be done ... but ....

I have a bunch of Ubiquity UbiFi access points around the house with
wired backhaul to the router. They can also work with wireless backhaul,
but we were having the house rewired so putting a load of CAT6 in, and a
POE switch, was a no-brainer.

They do exactly that. As a device moves between areas with different APs
the APs detect which has the best signal and the one with the lower
signal strength drops the connection. The device then reconnects and
picks the one with the stronger signal.

They've been in place about four years, now, and seem to work well.

--
Cheers,
Daniel.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 12/10/25 04:14, Andy Burns wrote:

c186282 wrote:

   I think it was you ... said how a cam would
   more or less drop out when the Big Red Truck
   was there.

No, maybe TNP said his oil level monitor would drop out?

Posting traffic has considerably increased of late,
partly my "fault" ... but COSLM was kind of dying
and that would have been tragic. Forgive the sort
of off-topic stuff, but it DOES keep minds alive -
you can't ALWAYS think about Linux without kind
of seizing up :-)

I do try to insert at least a little computing/
algo/Linux in as much as opportune.

I've had to skip subject threading because of all
the new postings ... just datetime sorting now.

So, yes, I might have mixed you and another poster
up a bit.

However that poster WAS complaining of drop-outs
due to changes in the physical environ ... ie
large fire trucks pulling in and blocking the
wifi signal. For that, my rec of a decently placed
wifi extender IS a good cheap fix. If you keep
getting interference, try switching the IP cam
to the extender and see how that works ....
a $49.95 solution ........


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 10/12/2025 05:27, c186282 wrote:
  nastiness.

  Easiest ... add one wifi extender, log into
  the camera, see whether you get more bars
  with the main or the extender.

Actually something that might be of interest...

# iwlist wlan0 scanning | grep -e Cell -e Channel -e Quality -e Encrypt
-e ESSID

Shows all stations visible to a ZeroW ... run it as root...

Cell 01 - Address: 00:1D:AA:79:78:40
Channel:7
Frequency:2.442 GHz (Channel 7)
Quality=44/70 Signal level=-66 dBm
Encryption key:on
ESSID:"Wifi1"
Cell 02 - Address: 30:46:9A:A2:89:F6
Channel:13
Frequency:2.472 GHz (Channel 13)
Quality=51/70 Signal level=-59 dBm
Encryption key:on
ESSID:"wifi2"
Cell 03 - Address: 74:4D:28:4A:21:86
Channel:3
Frequency:2.422 GHz (Channel 3)
Quality=35/70 Signal level=-75 dBm
Encryption key:on
ESSID:"wifi3"
etc etc.


--
"First, find out who are the people you can not criticise. They are your oppressors."
- George Orwell


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 10/12/2025 10:53, c186282 wrote:

On 12/10/25 05:24, The Natural Philosopher wrote:

On 10/12/2025 10:02, c186282 wrote:

On 12/10/25 04:14, Andy Burns wrote:

c186282 wrote:

   I think it was you ... said how a cam would
   more or less drop out when the Big Red Truck
   was there.

No, maybe TNP said his oil level monitor would drop out?

   Posting traffic has considerably increased of late,
   partly my "fault" ... but COSLM was kind of dying
   and that would have been tragic. Forgive the sort
   of off-topic stuff, but it DOES keep minds alive -
   you can't ALWAYS think about Linux without kind
   of seizing up :-)

I stated for te record and for the interest of others doing outside
wifi coupled IOT shit that rain wind and possibly cars made a difference.

Someone else remarked that so did fire trucks.

The downside of the new oil monitor is that is is so accurate - to
within a litre it seems - that I can visibly see how much a shower or
washing the dishes costs me, and a cold night is very expensive. :-)
LOL.

Now off to write the software that will look at it for me and warn me
of things by email.
So I can get on with the next project.

  Somebody said something interesting ... that
  the effect of the Big Red Truck on the wifi
  signal kind of turned it into a radio proximity
  sensor. Ya know, THAT might be useful ......

That was in fact how Radar was born. Engineers noted that HF radio was affected by planes flying overhead.

Chain Home was built to run between 20MHz and 55MHz.

The Germans sent a Zeppelin to investigate,m but they spotted it miles
away and switched it off.

Germany thought the frequency was too low for proper radiolocation.
They thought it was probably a LORAN style system for navigation.

At that time I don't think a radio valve (tube) was much uses over about 150MHz. They had to sue klystrons and later magnetrons for transmitting GigaHertz stuff.

  As for The Project ... with enough interesting
  input The Project might change ... to something
  More Interesting  :-)

  Hmmm ... My stuff gives off wifi, and there are a
  few neighbors too. MIGHT be I could sample signal
  strength and come up with certain 'fingerprints' -
  like of vehicles driving by or, more important,
  the Amazon truck pulling into my driveway ...
  BEEP !!!

It is certainly doable at 2.4 GHz.

Build a directional mirror - parabolic, and send a wifi signal up it.

Point it away from a similarly equipped receiver, and wait for something
to reflect it back.

Or just spend $2 for one already built ready to hook up to your Pi.

https://thepihut.com/products/microwave-motion-sensor-rcwl-0516

  See how little stuff can spawn bigger ideas ?  :-)

--
"Women actually are capable of being far more than the feminists will
let them."




--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 10/12/2025 13:01, Daniel James wrote:

On 10/12/2025 10:29, c186282 wrote:

What we WANT is for a device connection to use
the BEST signal - whether that's the primary
router or an extender - and switch back and
forth automatically depending on the connection
quality. Looks like it CAN be done ... but ....

I have a bunch of Ubiquity UbiFi access points around the house with
wired backhaul to the router. They can also work with wireless backhaul,
but we were having the house rewired so putting a load of CAT6 in, and a
POE switch, was a no-brainer.

They do exactly that. As a device moves between areas with different APs
the APs detect which has the best signal and the one with the lower
signal strength drops the connection. The device then reconnects and
picks the one with the stronger signal.

Aha. So that's how they do it. No intelligence required in the client

So they talk to each other 'my client needs to be your client.'

That only happens with me when they go out of range completely.

They've been in place about four years, now, and seem to work well.

--
Religion is regarded by the common people as true, by the wise as
foolish, and by the rulers as useful.

(Seneca the Younger, 65 AD)



--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 10/12/2025 10:36, c186282 wrote:

On 12/10/25 04:55, The Natural Philosopher wrote:

On 10/12/2025 05:27, c186282 wrote:
   nastiness.

   Easiest ... add one wifi extender, log into
   the camera, see whether you get more bars
   with the main or the extender.

Actually something that might be of interest...

# iwlist wlan0 scanning | grep -e Cell -e Channel -e Quality -e
Encrypt -e ESSID

Shows all stations visible to a ZeroW  ... run it as root...

          Cell 01 - Address: 00:1D:AA:79:78:40
                     Channel:7
                     Frequency:2.442 GHz (Channel 7)
                     Quality=44/70  Signal level=-66 dBm
                     Encryption key:on
                     ESSID:"Wifi1"
           Cell 02 - Address: 30:46:9A:A2:89:F6
                     Channel:13
                     Frequency:2.472 GHz (Channel 13)
                     Quality=51/70  Signal level=-59 dBm
                     Encryption key:on
                     ESSID:"wifi2"
           Cell 03 - Address: 74:4D:28:4A:21:86
                     Channel:3
                     Frequency:2.422 GHz (Channel 3)
                     Quality=35/70  Signal level=-75 dBm
                     Encryption key:on
                     ESSID:"wifi3"
etc etc.

  Interesting.

  DOES show a number of "cells" ... but not the ESSID of
  my extender for some reason.

That may be spoofing someone elses...
Try' iwlist wlan0 scanning' on its own

Ther is a lot more info

  In theory, this sort of data could be used by a
  relatively simple daemon to switch back and
  forth to the 'best' signal. The old CL stuff
  is fine ... but can sometimes be replaced by
  half a dozen lines of more-comprehensible Python.

Its called 'network manager' but its not very good.






--
?Progress is precisely that which rules and regulations did not foresee,?

? Ludwig von Mises


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 10/12/2025 08:15, Andy Burns wrote:

c186282 wrote:

judging by the problem you claimed, your
ÿÿ easy fix is an extender.

I didn't say there was a problem, just that you can notice signal levels
go up and down depending on the presence or absence of a big red truck.

Just about anything messes 2.4GHz. I have no idea what modulation schema
wifi uses but it's probably not able to handle *changing* multipath.

Making the wifi itself into a motion detector...



--
?A leader is best When people barely know he exists. Of a good leader,
who talks little,When his work is done, his aim fulfilled,They will say,
?We did this ourselves.?

? Lao Tzu, Tao Te Ching


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 10/12/2025 10:02, c186282 wrote:

On 12/10/25 04:14, Andy Burns wrote:

c186282 wrote:

ÿÿ I think it was you ... said how a cam would
ÿÿ more or less drop out when the Big Red Truck
ÿÿ was there.

No, maybe TNP said his oil level monitor would drop out?

ÿ Posting traffic has considerably increased of late,
ÿ partly my "fault" ... but COSLM was kind of dying
ÿ and that would have been tragic. Forgive the sort
ÿ of off-topic stuff, but it DOES keep minds alive -
ÿ you can't ALWAYS think about Linux without kind
ÿ of seizing up :-)

I stated for te record and for the interest of others doing outside wifi coupled IOT shit that rain wind and possibly cars made a difference.

Someone else remarked that so did fire trucks.

The downside of the new oil monitor is that is is so accurate - to
within a litre it seems - that I can visibly see how much a shower or
washing the dishes costs me, and a cold night is very expensive. :-)
LOL.

Now off to write the software that will look at it for me and warn me of things by email.
So I can get on with the next project.


--
?A leader is best When people barely know he exists. Of a good leader,
who talks little,When his work is done, his aim fulfilled,They will say,
?We did this ourselves.?

? Lao Tzu, Tao Te Ching


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 10/12/2025 09:14, Andy Burns wrote:

c186282 wrote:

ÿÿ I think it was you ... said how a cam would
ÿÿ more or less drop out when the Big Red Truck
ÿÿ was there.

No, maybe TNP said his oil level monitor would drop out?

Well that's what started it. he confirmed it with a Big Red Truck? anecdote. Anyway its all more or less confirmation that wifi is unstable and to be avoided if possible., and to be treated with suspicion if you have to
deploy it.



--
?A leader is best When people barely know he exists. Of a good leader,
who talks little,When his work is done, his aim fulfilled,They will say,
?We did this ourselves.?

? Lao Tzu, Tao Te Ching


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 10/12/2025 10:29, c186282 wrote:

On 12/10/25 04:47, The Natural Philosopher wrote:

I ought to resurrect 27MHz.. that is still free-ish

ÿ It can be good for some stuff, alas not IP
ÿ cams and other higher-bandwidth devices.

Yeah. You can get maybe 50kbps out of 27MHz Probably enough fir a very
low res cam.,

ÿ Hmmm ... maybe 300 Hz ? Goes everywhere !

Short to medium wave the best, as used in ADSL.

ÿÿ Pity nobody makes a 5ghz "viewer" so you can
ÿÿ get at least a fuzzy picture of the signal at
ÿÿ different placesÿ ?

Well they do. Its called a smart phone.

ÿ "Bars" ??? How CRUDE !ÿ :-)

Er no, Not bars.

https://play.google.com/store/apps/details?id=abdelrahman.wifianalyzerpro

ÿ I wanna SEE colors on the walls.

Take more LSD

ÿ DID add a wlan1 ... but, as was, not really useful.
ÿ You could connect to one, or the other, but there's
ÿ no inherent fail-over. Apparently there IS some
ÿ software, and/or evil config/iptables, fixes ...
ÿ but kinda icky.

No,. it just needs setting up.
I looked into ot and decided life was too shoryt

ÿ What we WANT is for a device connection to use
ÿ the BEST signal - whether that's the primary
ÿ router or an extender - and switch back and
ÿ forth automatically depending on the connection
ÿ quality. Looks like it CAN be done ... but ....

Yes. unfortunately that is not how *most* wifi works
]
--
In a Time of Universal Deceit, Telling the Truth Is a Revolutionary Act.

- George Orwell


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 11/12/2025 04:12, c186282 wrote:

Everybody thought
  that the 1950s were the pinnacle of modern civ ...
  "What else WOULD you need to add in ???".

Reminds me of a brand new factory in Jo'burg. Solid concrete walls and a
tin roof. And nnot a single socket or light that worked.

The contractor brought in to fix it spent 20 minutes looking and then
said 'Fuck that - get the Kangas' and simply chipped new channels for *everything*. Laid in pipe conduit and got wiring.

Before the days of computers that was, let alone networking. We used Telex.

--
The urge to save humanity is almost always a false front for the urge to
rule.
? H. L. Mencken, American journalist, 1880-1956


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2025-12-09 11:47, The Natural Philosopher wrote:

First of all thanks to all those who responded on my first efforts to
put a battery power Pi Pico W outside and have it phone home.

Having eliminated temperature and supply voltage as issues, I delved
into wifi and router logs, and it was clear that it was sometimes
getting a DHCP lease and even occasionally opening a TCP/IP connections
and sending data. And might be dependent on where I parked the car and
the weather.

I tried putting a tin tray behind the router and that made it worse.

Now the layout was that a ground floor router through the window and the garage was not very good at about 30m range.

Then I remembered I had put an Ethernet port in an upstairs bedroom by
the window in case I wanted to use it as an office.

It was further away - 35m or so - but much less cluttered path. It just
had to go through a corner of the garage.

Instantly the router reported about 8-10dB more signal and almost
reliable comms resulted.

Two ideas.

Some routers can steer the signal horizontally; the technology is called "MIMO" (https://en.wikipedia.org/wiki/MIMO). You notice because the
router has multiple antenas, maybe four.

Then you can replace the antena on the router or the remote with a
directional WiFi antena. Home made with a box of Pringles. just google
for "pringles wifi antenna". I made one and it actually works. But maybe
they are sold, too.

...

And I knew all that trig would come in handy one day :-)

You can calculate it numerically on a computer, by calculating the
aproximate integral ;-)

--
Cheers, Carlos.
ES??, EU??;

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2025-12-10 11:24, The Natural Philosopher wrote:

On 10/12/2025 10:02, c186282 wrote:

On 12/10/25 04:14, Andy Burns wrote:

c186282 wrote:

ÿÿ I think it was you ... said how a cam would
ÿÿ more or less drop out when the Big Red Truck
ÿÿ was there.

No, maybe TNP said his oil level monitor would drop out?

ÿÿ Posting traffic has considerably increased of late,
ÿÿ partly my "fault" ... but COSLM was kind of dying
ÿÿ and that would have been tragic. Forgive the sort
ÿÿ of off-topic stuff, but it DOES keep minds alive -
ÿÿ you can't ALWAYS think about Linux without kind
ÿÿ of seizing up :-)

I stated for te record and for the interest of others doing outside wifi coupled IOT shit that rain wind and possibly cars made a difference.

Someone else remarked that so did fire trucks.

The downside of the new oil monitor is that is is so accurate - to
within a litre it seems - that I can visibly see how much a shower or washing the dishes costs me, and a cold night is very expensive. :-)
LOL.

Now off to write the software that will look at it for me and warn me of things by email.
So I can get on with the next project.

You mentioned thieves stealing fuel. You can also monitor for that. You
would need a fuel flow meter on the fuel line, or a sensor telling when
the furnace is working. Compare with the tank level decreasing rapidly.

--
Cheers, Carlos.
ES??, EU??;

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 12/11/25 03:48, The Natural Philosopher wrote:

On 11/12/2025 04:12, c186282 wrote:

Everybody thought
   that the 1950s were the pinnacle of modern civ ...
   "What else WOULD you need to add in ???".

Reminds me of a brand new factory in Jo'burg. Solid concrete walls and a
tin roof. And nnot a single socket or light that worked.

The contractor brought in to fix it spent 20 minutes looking and then
said 'Fuck that - get the Kangas' and simply chipped new channels for *everything*. Laid in pipe conduit and got wiring.

Before the days of computers that was, let alone networking. We used Telex.

Esp in the 50s, well, they DID really think they
were The Pinnacle. Everyone would always have
their rotary-dial telephones, only a few, and
need just a very few lights and sockets. So, they
built, often large, structures reflecting that
philosophy.

Solid concrete ... or at least with gaps you could
not GET to once construction finished.

My last office, they wanted to add a couple of
extensions. Had to force the builders to drill
a couple of 2" holes through solid concrete
lintels just so we could run comm/net cables.
The lintels didn't really hold up much weight
but were huge regardless. Took them like half
a day to put the two holes though the lintels,
and they hit a piece of rebar in the process.

This was well before crap gypsum-board walls and
drop ceilings.




--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2025-12-10 11:02, c186282 wrote:

ÿ I've had to skip subject threading because of all
ÿ the new postings ... just datetime sorting now.

That's the fault of your client software. Thunderbird threads correctly
even if the subject changes. I don't know what you are using :-?

--
Cheers, Carlos.
ES??, EU??;

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 12/12/2025 10:39, Andy Burns wrote:

The Natural Philosopher wrote:

the sensor I built on the tank has no power except batteries: So it
only wakes up occasionally and draws nanoamps in between.
I have completed the warning software that looks for low oil levels,
loss of communication, a failing battery and unexpected changes in oil
level, BUT it cannot do that in real time as the unit is only powered
up for a minute or so every couple of hours.

Depending on how long the batteries last I may increase the frequency
of operation.

Worth trying to send the data as UDP rather than TCP? if it fits in a
single packet,the receiver doesn't have to track the position within a stream ...

Well the daemon runs under xinetd...for sheer laziness. I guess I could
make it UDP.

But I don't know what problem that would solve.

--
Microsoft : the best reason to go to Linux that ever existed.


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 11/12/2025 21:06, Carlos E.R. wrote:

On 2025-12-10 11:24, The Natural Philosopher wrote:

On 10/12/2025 10:02, c186282 wrote:

On 12/10/25 04:14, Andy Burns wrote:

c186282 wrote:

   I think it was you ... said how a cam would
   more or less drop out when the Big Red Truck
   was there.

No, maybe TNP said his oil level monitor would drop out?

   Posting traffic has considerably increased of late,
   partly my "fault" ... but COSLM was kind of dying
   and that would have been tragic. Forgive the sort
   of off-topic stuff, but it DOES keep minds alive -
   you can't ALWAYS think about Linux without kind
   of seizing up :-)

I stated for te record and for the interest of others doing outside
wifi coupled IOT shit that rain wind and possibly cars made a difference.

Someone else remarked that so did fire trucks.

The downside of the new oil monitor is that is is so accurate - to
within a litre it seems - that I can visibly see how much a shower or
washing the dishes costs me, and a cold night is very expensive. :-)
LOL.

Now off to write the software that will look at it for me and warn me
of things by email.
So I can get on with the next project.

You mentioned thieves stealing fuel. You can also monitor for that. You would need a fuel flow meter on the fuel line, or a sensor telling when
the furnace is working. Compare with the tank level decreasing rapidly.

The problem is that the sensor I built on the tank has no power except batteries: So it only wakes up occasionally and draws nanoamps in between.
I have completed the warning software that looks for low oil levels,
loss of communication, a failing battery and unexpected changes in oil
level, BUT it cannot do that in real time as the unit is only powered up
for a minute or so every couple of hours.

Depending on how long the batteries last I may increase the frequency of operation. But it can never be 'real time'



--
If you tell a lie big enough and keep repeating it, people will
eventually come to believe it. The lie can be maintained only for such
time as the State can shield the people from the political, economic
and/or military consequences of the lie. It thus becomes vitally
important for the State to use all of its powers to repress dissent, for
the truth is the mortal enemy of the lie, and thus by extension, the
truth is the greatest enemy of the State.

Joseph Goebbels





--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2025-12-12 11:26, The Natural Philosopher wrote:

On 11/12/2025 21:06, Carlos E.R. wrote:

On 2025-12-10 11:24, The Natural Philosopher wrote:

On 10/12/2025 10:02, c186282 wrote:

On 12/10/25 04:14, Andy Burns wrote:

c186282 wrote:

Now off to write the software that will look at it for me and warn me
of things by email.
So I can get on with the next project.

You mentioned thieves stealing fuel. You can also monitor for that.
You would need a fuel flow meter on the fuel line, or a sensor telling
when the furnace is working. Compare with the tank level decreasing
rapidly.

The problem is that the sensor I built on the tank has no power except batteries: So it only wakes up occasionally and draws nanoamps in between.
I have completed the warning software that looks for low oil levels,
loss of communication, a failing battery and unexpected changes in oil level, BUT it cannot do that in real time as the unit is only powered up
for a minute or so every couple of hours.

Depending on how long the batteries last I may increase the frequency of operation. But it can never be 'real time'

Ah.

What about a small solar panel and rechargeable batteries?

--
Cheers, Carlos.
ES??, EU??;

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 11/12/2025 21:18, Carlos E.R. wrote:

Two ideas.

Some routers can steer the signal horizontally; the technology is called "MIMO" (https://en.wikipedia.org/wiki/MIMO). You notice because the
router has multiple antenas, maybe four.

Then you can replace the antena on the router

What antenna on the router?

It's just a wifi bridge with an internal something or other.

https://www.netxl.com/wifi-access-points/mikrotik-routerboard-rb951ui-2nd-wifi-4-access-point/

Its actually very very cheap and has been 'good enough'


> or the remote with a

directional WiFi antena.

That gets complicated. I am trying easy shit first :-)

P Pico W doesn't have an 'antenna' either. Just some PCB traces.

Home made with a box of Pringles. just google
for "pringles wifi antenna". I made one and it actually works. But maybe they are sold, too.

Everything is possible. I am lazy. I do what is necessary to achieve
desired result and no more.

For now I seem to have adequate connectivity.

--
I would rather have questions that cannot be answered...
...than to have answers that cannot be questioned

Richard Feynman




--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 11/12/2025 21:18, Carlos E.R. wrote:

On 2025-12-09 11:47, The Natural Philosopher wrote:

First of all thanks to all those who responded on my first efforts to
put a battery power Pi Pico W outside and have it phone home.

Having eliminated temperature and supply voltage as issues, I delved
into wifi and router logs, and it was clear that it was sometimes
getting a DHCP lease and even occasionally opening a TCP/IP
connections and sending data. And might be dependent on where I parked
the car and the weather.

I tried putting a tin tray behind the router and that made it worse.

Now the layout was that a ground floor router through the window and
the garage was not very good at about 30m range.

Then I remembered I had put an Ethernet port in an upstairs bedroom by
the window in case I wanted to use it as an office.

It was further away - 35m or so - but much less cluttered path. It
just had to go through a corner of the garage.

Instantly the router reported about 8-10dB more signal and almost
reliable comms resulted.

Two ideas.

Some routers can steer the signal horizontally; the technology is called "MIMO" (https://en.wikipedia.org/wiki/MIMO). You notice because the
router has multiple antenas, maybe four.

Then you can replace the antena on the router or the remote with a directional WiFi antena. Home made with a box of Pringles. just google
for "pringles wifi antenna". I made one and it actually works. But maybe they are sold, too.

I sorta tried that without huge success, In fact I am getting up to 12dB variation in signal due to who knows what?

The setup is all somewhat experimental. At least for now the software
is more or less stable - I have a few hanging daemons if the link goes
down mid message - but that is easily fixed .

...

And I knew all that trig would come in handy one day :-)

You can calculate it numerically on a computer, by calculating the aproximate integral ;-)

Huh? it can be as exact as your measurements are.
No 'approximations' here...

diameter= tankDepth - offset;
radius = diameter * 0.5;
y = echoDepth - offset -radius;
theta = asin( y / radius);
x = radius * cos(theta);
pie= radius * radius * theta;
delta = x * y;
area= (M_PI * radius *radius)/2 - (pie + delta);
volume=(area/(M_PI * radius *radius ))*tankVolume;

That is about ultimately three days of work. It is redundant but I think
gcc can optimise out the intermediary variables that I used to make sure
even I could understand it.



What has been encouraging is the pinpoint accuracy of the measurements.
Once in a stable environment the ultrasonics are very precise. something
like a mm or two in a couple of metres. Probably more precise than the
speed of sound in air of variable pressures would justify, or indeed the expansion of the oil in warmer temperatures.

LOL.

Maybe I have built the world's most complicated barometer.

--
?it should be clear by now to everyone that activist environmentalism
(or environmental activism) is becoming a general ideology about humans,
about their freedom, about the relationship between the individual and
the state, and about the manipulation of people under the guise of a
'noble' idea. It is not an honest pursuit of 'sustainable development,'
a matter of elementary environmental protection, or a search for
rational mechanisms designed to achieve a healthy environment. Yet
things do occur that make you shake your head and remind yourself that
you live neither in Joseph Stalin?s Communist era, nor in the Orwellian
utopia of 1984.?

Vaclav Klaus


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 12/12/2025 11:19, Carlos E.R. wrote:

On 2025-12-12 11:26, The Natural Philosopher wrote:

On 11/12/2025 21:06, Carlos E.R. wrote:

On 2025-12-10 11:24, The Natural Philosopher wrote:

On 10/12/2025 10:02, c186282 wrote:

On 12/10/25 04:14, Andy Burns wrote:

c186282 wrote:

Now off to write the software that will look at it for me and warn
me of things by email.
So I can get on with the next project.

You mentioned thieves stealing fuel. You can also monitor for that.
You would need a fuel flow meter on the fuel line, or a sensor
telling when the furnace is working. Compare with the tank level
decreasing rapidly.

The problem is that the sensor I built on the tank has no power except
batteries: So it only wakes up occasionally and draws nanoamps in
between.
I have completed the warning software that looks for low oil levels,
loss of communication, a failing battery and unexpected changes in oil
level, BUT it cannot do that in real time as the unit is only powered
up for a minute or so every couple of hours.

Depending on how long the batteries last I may increase the frequency
of operation. But it can never be 'real time'

Ah.

What about a small solar panel and rechargeable batteries?

Yes. That is in the 'lemme think about that' pile...
Not that there is much sun here..

At this time of year.

And where the tank it is likely to get overgrown or shat on by birds



--
?The ultimate result of shielding men from the effects of folly is to
fill the world with fools.?

Herbert Spencer


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 12/12/2025 11:41, Andy Burns wrote:

The Natural Philosopher wrote:

Well the daemon runs under xinetd...for sheer laziness. I guess I
could make it UDP.

But I don't know what problem that would solve.

The data would arrive if a single packet got through the fog, whereas
with tcp at least dour packets on sequence need to make it (or get
retried) with UDP you could afford to spray each packet half a dozen
times and if one of them makes it, you're good ...

Oh, ok...

--
?The ultimate result of shielding men from the effects of folly is to
fill the world with fools.?

Herbert Spencer


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 12/12/25 06:41, Andy Burns wrote:

The Natural Philosopher wrote:

Well the daemon runs under xinetd...for sheer laziness. I guess I
could make it UDP.

But I don't know what problem that would solve.

The data would arrive if a single packet got through the fog, whereas
with tcp at least dour packets on sequence need to make it (or get
retried) with UDP you could afford to spray each packet half a dozen
times and if one of them makes it, you're good ...

I once made a bi-directional client/server setup,
first Python, then 'C'. One variant was TCP, the
other UDP. Probably could have used a config file
or defs ... but I never got to it.

On a clean LAN, both worked perfectly. However
with some outdoor devices (Pi2 + wifi dongle as
best I recall) both approaches had issues kind
of similar to what you described.

TCP, while "error resistant", was often VERY iffy.
UDP - well - easier/smaller to send. You could
scan each packet for obvious errors and, if a
fail, could ask for it again or just let the
pgm work around to sending that data again.

For almost all modern apps, TCP is best by far.
However iffy situations CAN still exist, so
UDP you add some IQ to MIGHT be better.

As I've said elsewhere, wifi can sometimes be
black magic. Weird RF shadows and multipaths
can be anywhere and it's very hard to tell
what's perfect placement.

Hmm ... apparently CANbus can be sent over
wifi - but you lose some error-checking so
there's no gain. There are various dongles
for lower-freq data transmission too, but
never got around to trying them. Fidelity
might be worth losing some speed.


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2025-12-12 12:28, The Natural Philosopher wrote:

On 11/12/2025 21:18, Carlos E.R. wrote:

Two ideas.

Some routers can steer the signal horizontally; the technology is
called "MIMO" (https://en.wikipedia.org/wiki/MIMO). You notice because
the router has multiple antenas, maybe four.

Then you can replace the antena on the router

What antenna on the router?

It's just a wifi bridge with an internal something or other.

Ah, pity. Many AP have external antenas that are screwed on a socket.

https://www.netxl.com/wifi-access-points/mikrotik-routerboard- rb951ui-2nd-wifi-4-access-point/

Its actually very very cheap and has been 'good enough'

Barely :-)

or the remote with a

directional WiFi antena.

That gets complicated. I am trying easy shit first :-)

P Pico W doesn't have an 'antenna' either. Just some PCB traces.

Yeah, well.

Home made with a box of Pringles. just google for "pringles wifi
antenna". I made one and it actually works. But maybe they are sold, too.

Everything is possible. I am lazy. I do what is necessary to achieve
desired result and no more.

For now I seem to have adequate connectivity.

Of course, that is enough.


--
Cheers, Carlos.
ES??, EU??;

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2025-12-13 05:42, c186282 wrote:

On 12/12/25 06:19, Carlos E.R. wrote:

On 2025-12-12 11:26, The Natural Philosopher wrote:

On 11/12/2025 21:06, Carlos E.R. wrote:

On 2025-12-10 11:24, The Natural Philosopher wrote:

On 10/12/2025 10:02, c186282 wrote:

On 12/10/25 04:14, Andy Burns wrote:

What about a small solar panel and rechargeable batteries?

ÿ Seeed sells the "LiPo Rider Plus". After checking
ÿ several brands of 'solar charge controllers' these
ÿ were the ones I chose to power my field projects.
ÿ Most of the others did NOT cap the voltage very
ÿ well, or at all, so the sun comes out bright and you
ÿ might send 6+ into your 3.1v device.

ÿ Combined with a 3 to 5 watt panel they'll keep even
ÿ intermittent non-nano-power projects going.

ÿ Beware the quality of the batteries though ... got
ÿ some no-names, about 50x50x10mm square, that were
ÿ generally good - but one DID explode on me, inside
ÿ the office building, when I barely touched it. Had
ÿ not been charged for months either. Oh well, nothing
ÿ to do but watch the big crimson flame .......

ÿ Fire control IS a priority with lithiums.

Huh. That's not good when the thing is intended to be near a oil tank.

--
Cheers, Carlos.
ES??, EU??;

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2025-12-12 11:41, The Natural Philosopher wrote:

On 11/12/2025 21:18, Carlos E.R. wrote:

On 2025-12-09 11:47, The Natural Philosopher wrote:

First of all thanks to all those who responded on my first efforts to
put a battery power Pi Pico W outside and have it phone home.

Having eliminated temperature and supply voltage as issues, I delved
into wifi and router logs, and it was clear that it was sometimes
getting a DHCP lease and even occasionally opening a TCP/IP
connections and sending data. And might be dependent on where I
parked the car and the weather.

I tried putting a tin tray behind the router and that made it worse.

Now the layout was that a ground floor router through the window and
the garage was not very good at about 30m range.

Then I remembered I had put an Ethernet port in an upstairs bedroom
by the window in case I wanted to use it as an office.

It was further away - 35m or so - but much less cluttered path. It
just had to go through a corner of the garage.

Instantly the router reported about 8-10dB more signal and almost
reliable comms resulted.

Two ideas.

Some routers can steer the signal horizontally; the technology is
called "MIMO" (https://en.wikipedia.org/wiki/MIMO). You notice because
the router has multiple antenas, maybe four.

Then you can replace the antena on the router or the remote with a
directional WiFi antena. Home made with a box of Pringles. just google
for "pringles wifi antenna". I made one and it actually works. But
maybe they are sold, too.

I sorta tried that without huge success, In fact I am getting up to 12dB variation in signal due to who knows what?

The setup is all somewhat experimental. At leastÿ for now the software
is more or less stable - I have a few hanging daemons if the link goes
down mid message - but that is easily fixed .

...

And I knew all that trig would come in handy one day :-)

You can calculate it numerically on a computer, by calculating the
aproximate integral ;-)

Huh? it can be as exact as your measurements are.
No 'approximations' here...

ÿÿÿÿÿÿÿ diameter= tankDepth - offset;
ÿÿÿÿÿÿÿ radius = diameter * 0.5;
ÿÿÿÿÿÿÿ y = echoDepth - offset -radius;
ÿÿÿÿÿÿÿ theta = asin( y / radius);
ÿÿÿÿÿÿÿ x = radius * cos(theta);
ÿÿÿÿÿÿÿ pie= radius * radius * theta;
ÿÿÿÿÿÿÿ delta = x * y;
ÿÿÿÿÿÿÿ area= (M_PI * radius *radius)/2 - (pie + delta);
ÿÿÿÿÿÿÿ volume=(area/(M_PI * radius *radius ))*tankVolume;

That is about ultimately three days of work. It is redundant but I think
gcc can optimise out the intermediary variables that I used to make sure even I could understand it.

You can aproximate the chord with a rectangle. If you divide the chord
in two, it is two rectangles. Up to a thousand rectangles, or a million.
The numerical result is close to the real result with a math formula.
Kind of Runge-Kutta.

:-D

Or ask ChatGPT for the formula. I sure don't remember it, I doubt I ever
saw it.

What has been encouraging is the pinpoint accuracy of the measurements.
Once in a stable environment the ultrasonics are very precise. something like a mm or two in a couple of metres. Probably more precise than the
speed of sound in air of variable pressures would justify, or indeed the expansion of the oil in warmer temperatures.

LOL.

Maybe I have built the world's most complicated barometer.

--
Cheers, Carlos.
ES??, EU??;

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)