Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.raspberry-pi > #37378 > unrolled thread
| Started by | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| First post | 2025-12-09 10:47 +0000 |
| Last post | 2025-12-25 18:44 +0000 |
| Articles | 20 on this page of 80 — 13 participants |
Back to article view | Back to comp.sys.raspberry-pi
More on wifi range - Pi PICO W Oil level sensor The Natural Philosopher <tnp@invalid.invalid> - 2025-12-09 10:47 +0000
Re: More on wifi range - Pi PICO W Oil level sensor Andy Burns <usenet@andyburns.uk> - 2025-12-09 11:57 +0000
Re: More on wifi range - Pi PICO W Oil level sensor The Natural Philosopher <tnp@invalid.invalid> - 2025-12-09 14:07 +0000
Re: More on wifi range - Pi PICO W Oil level sensor Rich <rich@example.invalid> - 2025-12-09 19:14 +0000
Re: More on wifi range - Pi PICO W Oil level sensor The Natural Philosopher <tnp@invalid.invalid> - 2025-12-09 19:17 +0000
Re: More on wifi range - Pi PICO W Oil level sensor c186282 <c186282@nnada.net> - 2025-12-09 21:19 -0500
Re: More on wifi range - Pi PICO W Oil level sensor Andy Burns <usenet@andyburns.uk> - 2025-12-10 05:18 +0000
Re: More on wifi range - Pi PICO W Oil level sensor c186282 <c186282@nnada.net> - 2025-12-10 00:27 -0500
Re: More on wifi range - Pi PICO W Oil level sensor Andy Burns <usenet@andyburns.uk> - 2025-12-10 05:38 +0000
Re: More on wifi range - Pi PICO W Oil level sensor c186282 <c186282@nnada.net> - 2025-12-10 02:13 -0500
Re: More on wifi range - Pi PICO W Oil level sensor Andy Burns <usenet@andyburns.uk> - 2025-12-10 08:12 +0000
Re: More on wifi range - Pi PICO W Oil level sensor Andy Burns <usenet@andyburns.uk> - 2025-12-10 08:15 +0000
Re: More on wifi range - Pi PICO W Oil level sensor c186282 <c186282@nnada.net> - 2025-12-10 03:56 -0500
Re: More on wifi range - Pi PICO W Oil level sensor Andy Burns <usenet@andyburns.uk> - 2025-12-10 09:14 +0000
Re: More on wifi range - Pi PICO W Oil level sensor The Natural Philosopher <tnp@invalid.invalid> - 2025-12-10 09:59 +0000
Re: More on wifi range - Pi PICO W Oil level sensor c186282 <c186282@nnada.net> - 2025-12-10 05:02 -0500
Re: More on wifi range - Pi PICO W Oil level sensor The Natural Philosopher <tnp@invalid.invalid> - 2025-12-10 10:24 +0000
Re: More on wifi range - Pi PICO W Oil level sensor c186282 <c186282@nnada.net> - 2025-12-10 05:53 -0500
Re: More on wifi range - Pi PICO W Oil level sensor The Natural Philosopher <tnp@invalid.invalid> - 2025-12-10 11:45 +0000
Re: More on wifi range - Pi PICO W Oil level sensor "Carlos E.R." <robin_listas@es.invalid> - 2025-12-11 22:06 +0100
Re: More on wifi range - Pi PICO W Oil level sensor The Natural Philosopher <tnp@invalid.invalid> - 2025-12-12 10:26 +0000
Re: More on wifi range - Pi PICO W Oil level sensor Andy Burns <usenet@andyburns.uk> - 2025-12-12 10:39 +0000
Re: More on wifi range - Pi PICO W Oil level sensor The Natural Philosopher <tnp@invalid.invalid> - 2025-12-12 11:14 +0000
Re: More on wifi range - Pi PICO W Oil level sensor Andy Burns <usenet@andyburns.uk> - 2025-12-12 11:41 +0000
Re: More on wifi range - Pi PICO W Oil level sensor The Natural Philosopher <tnp@invalid.invalid> - 2025-12-12 12:10 +0000
Re: More on wifi range - Pi PICO W Oil level sensor c186282 <c186282@nnada.net> - 2025-12-13 01:19 -0500
Re: More on wifi range - Pi PICO W Oil level sensor "Carlos E.R." <robin_listas@es.invalid> - 2025-12-12 12:19 +0100
Re: More on wifi range - Pi PICO W Oil level sensor The Natural Philosopher <tnp@invalid.invalid> - 2025-12-12 12:10 +0000
Re: More on wifi range - Pi PICO W Oil level sensor c186282 <c186282@nnada.net> - 2025-12-12 23:42 -0500
Re: More on wifi range - Pi PICO W Oil level sensor "Carlos E.R." <robin_listas@es.invalid> - 2025-12-13 13:30 +0100
Re: More on wifi range - Pi PICO W Oil level sensor "Carlos E.R." <robin_listas@es.invalid> - 2025-12-11 22:03 +0100
Re: More on wifi range - Pi PICO W Oil level sensor The Natural Philosopher <tnp@invalid.invalid> - 2025-12-10 09:57 +0000
Re: More on wifi range - Pi PICO W Oil level sensor The Natural Philosopher <tnp@invalid.invalid> - 2025-12-10 09:55 +0000
Re: More on wifi range - Pi PICO W Oil level sensor c186282 <c186282@nnada.net> - 2025-12-10 05:36 -0500
Re: More on wifi range - Pi PICO W Oil level sensor The Natural Philosopher <tnp@invalid.invalid> - 2025-12-10 11:33 +0000
Re: More on wifi range - Pi PICO W Oil level sensor The Natural Philosopher <tnp@invalid.invalid> - 2025-12-10 09:47 +0000
Re: More on wifi range - Pi PICO W Oil level sensor c186282 <c186282@nnada.net> - 2025-12-10 05:29 -0500
Re: More on wifi range - Pi PICO W Oil level sensor The Natural Philosopher <tnp@invalid.invalid> - 2025-12-10 11:29 +0000
Re: More on wifi range - Pi PICO W Oil level sensor Daniel James <daniel@me.invalid> - 2025-12-10 13:01 +0000
Re: More on wifi range - Pi PICO W Oil level sensor The Natural Philosopher <tnp@invalid.invalid> - 2025-12-10 13:05 +0000
Re: More on wifi range - Pi PICO W Oil level sensor c186282 <c186282@nnada.net> - 2025-12-10 23:19 -0500
Re: More on wifi range - Pi PICO W Oil level sensor c186282 <c186282@nnada.net> - 2025-12-10 23:12 -0500
Re: More on wifi range - Pi PICO W Oil level sensor The Natural Philosopher <tnp@invalid.invalid> - 2025-12-11 08:48 +0000
Re: More on wifi range - Pi PICO W Oil level sensor c186282 <c186282@nnada.net> - 2025-12-11 04:19 -0500
Cable chasing (Was: More on wifi range - Pi PICO W Oil level sensor) Daniel James <daniel@me.invalid> - 2025-12-11 10:15 +0000
Inside out (Was: More on wifi range - Pi PICO W Oil level sensor) Daniel James <daniel@me.invalid> - 2025-12-11 10:23 +0000
Re: Inside out (Was: More on wifi range - Pi PICO W Oil level sensor) Lars Poulsen <lars@beagle-ears.com> - 2025-12-11 18:16 +0000
Re: Inside out (Was: More on wifi range - Pi PICO W Oil level sensor) John R Walliker <jrwalliker@gmail.com> - 2025-12-11 18:28 +0000
Re: Inside out (Was: More on wifi range - Pi PICO W Oil level sensor) "Carlos E.R." <robin_listas@es.invalid> - 2025-12-11 21:59 +0100
Re: Inside out (Was: More on wifi range - Pi PICO W Oil level sensor) The Natural Philosopher <tnp@invalid.invalid> - 2025-12-12 11:21 +0000
Re: Inside out (Was: More on wifi range - Pi PICO W Oil level sensor) "Carlos E.R." <robin_listas@es.invalid> - 2025-12-13 13:45 +0100
Re: Inside out (Was: More on wifi range - Pi PICO W Oil level sensor) Bob Martin <bob.martin@excite.com> - 2025-12-14 06:38 +0000
Re: Inside out (Was: More on wifi range - Pi PICO W Oil level sensor) The Natural Philosopher <tnp@invalid.invalid> - 2025-12-15 19:19 +0000
Re: More on wifi range - Pi PICO W Oil level sensor "Carlos E.R." <robin_listas@es.invalid> - 2025-12-11 22:18 +0100
Re: More on wifi range - Pi PICO W Oil level sensor The Natural Philosopher <tnp@invalid.invalid> - 2025-12-12 10:41 +0000
Re: More on wifi range - Pi PICO W Oil level sensor "Carlos E.R." <robin_listas@es.invalid> - 2025-12-13 13:57 +0100
Re: More on wifi range - Pi PICO W Oil level sensor The Natural Philosopher <tnp@invalid.invalid> - 2025-12-12 11:28 +0000
Re: More on wifi range - Pi PICO W Oil level sensor "Carlos E.R." <robin_listas@es.invalid> - 2025-12-13 13:56 +0100
Re: More on wifi range - Pi PICO W Oil level sensor John R Walliker <jrwalliker@gmail.com> - 2025-12-14 19:22 +0000
Re: More on wifi range - Pi PICO W Oil level sensor mm0fmf <none@invalid.com> - 2025-12-24 07:58 +0000
Re: More on wifi range - Pi PICO W Oil level sensor The Natural Philosopher <tnp@invalid.invalid> - 2025-12-24 12:16 +0000
Re: More on wifi range - Pi PICO W Oil level sensor John R Walliker <jrwalliker@gmail.com> - 2025-12-24 14:04 +0000
Re: More on wifi range - Pi PICO W Oil level sensor The Natural Philosopher <tnp@invalid.invalid> - 2025-12-24 14:23 +0000
Re: More on wifi range - Pi PICO W Oil level sensor "Kerr-Mudd, John" <admin@127.0.0.1> - 2025-12-24 17:00 +0000
Re: More on wifi range - Pi PICO W Oil level sensor The Natural Philosopher <tnp@invalid.invalid> - 2025-12-24 20:07 +0000
Re: More on wifi range - Pi PICO W Oil level sensor mm0fmf <none@invalid.com> - 2025-12-24 23:17 +0000
Re: More on wifi range - Pi PICO W Oil level sensor The Natural Philosopher <tnp@invalid.invalid> - 2025-12-25 03:23 +0000
Re: More on wifi range - Pi PICO W Oil level sensor rbowman <bowman@montana.com> - 2025-12-25 07:32 +0000
Re: More on wifi range - Pi PICO W Oil level sensor c186282 <c186282@nnada.net> - 2025-12-24 21:16 -0500
Re: More on wifi range - Pi PICO W Oil level sensor "Carlos E.R." <robin_listas@es.invalid> - 2025-12-27 21:51 +0100
Re: More on wifi range - Pi PICO W Oil level sensor The Natural Philosopher <tnp@invalid.invalid> - 2025-12-27 23:31 +0000
Re: More on wifi range - Pi PICO W Oil level sensor rbowman <bowman@montana.com> - 2025-12-27 23:58 +0000
Re: More on wifi range - Pi PICO W Oil level sensor Lars Poulsen <lars@beagle-ears.com> - 2025-12-24 23:01 +0000
Re: More on wifi range - Pi PICO W Oil level sensor rbowman <bowman@montana.com> - 2025-12-25 02:29 +0000
Re: More on wifi range - Pi PICO W Oil level sensor Lars Poulsen <lars@beagle-ears.com> - 2025-12-24 22:53 +0000
Re: More on wifi range - Pi PICO W Oil level sensor Robert Riches <spamtrap42@jacob21819.net> - 2025-12-25 03:25 +0000
Re: More on wifi range - Pi PICO W Oil level sensor The Natural Philosopher <tnp@invalid.invalid> - 2025-12-25 03:34 +0000
Re: More on wifi range - Pi PICO W Oil level sensor "Kerr-Mudd, John" <admin@127.0.0.1> - 2025-12-25 10:43 +0000
Re: More on wifi range - Pi PICO W Oil level sensor The Natural Philosopher <tnp@invalid.invalid> - 2025-12-25 11:43 +0000
Re: More on wifi range - Pi PICO W Oil level sensor rbowman <bowman@montana.com> - 2025-12-25 18:44 +0000
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2025-12-12 10:26 +0000 |
| Message-ID | <10hgqju$2r3rh$1@dont-email.me> |
| In reply to | #37431 |
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
[toc] | [prev] | [next] | [standalone]
| From | Andy Burns <usenet@andyburns.uk> |
|---|---|
| Date | 2025-12-12 10:39 +0000 |
| Message-ID | <mq29n8Fkbm0U1@mid.individual.net> |
| In reply to | #37433 |
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 ...
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2025-12-12 11:14 +0000 |
| Message-ID | <10hgtem$2r3rh$8@dont-email.me> |
| In reply to | #37434 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Andy Burns <usenet@andyburns.uk> |
|---|---|
| Date | 2025-12-12 11:41 +0000 |
| Message-ID | <mq2dc2FktbjU2@mid.individual.net> |
| In reply to | #37436 |
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 ...
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2025-12-12 12:10 +0000 |
| Message-ID | <10hh0oj$2r3rh$25@dont-email.me> |
| In reply to | #37440 |
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
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2025-12-13 01:19 -0500 |
| Message-ID | <Gp2cnVMsbIP3mKD0nZ2dnZfqn_ednZ2d@giganews.com> |
| In reply to | #37440 |
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.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-12-12 12:19 +0100 |
| Message-ID | <7bat0mxbob.ln2@Telcontar.valinor> |
| In reply to | #37433 |
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🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2025-12-12 12:10 +0000 |
| Message-ID | <10hh0mr$2r3rh$24@dont-email.me> |
| In reply to | #37438 |
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
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2025-12-12 23:42 -0500 |
| Message-ID | <Gp2cnVEsbIMuc6H0nZ2dnZfqn_ednZ2d@giganews.com> |
| In reply to | #37438 |
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: >>>>>> 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? 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.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-12-13 13:30 +0100 |
| Message-ID | <es201mxcdp.ln2@Telcontar.valinor> |
| In reply to | #37443 |
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🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2025-12-11 22:03 +0100 |
| Message-ID | <95or0mxr8h.ln2@Telcontar.valinor> |
| In reply to | #37407 |
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🇪🇺;
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2025-12-10 09:57 +0000 |
| Message-ID | <10hbg71$1di3b$3@dont-email.me> |
| In reply to | #37400 |
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
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2025-12-10 09:55 +0000 |
| Message-ID | <10hbg1l$1di3b$2@dont-email.me> |
| In reply to | #37396 |
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
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2025-12-10 05:36 -0500 |
| Message-ID | <JzCdnUcVx_m40KT0nZ2dnZfqn_GdnZ2d@giganews.com> |
| In reply to | #37404 |
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. 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.
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2025-12-10 11:33 +0000 |
| Message-ID | <10hblqd$1di3b$26@dont-email.me> |
| In reply to | #37411 |
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
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2025-12-10 09:47 +0000 |
| Message-ID | <10hbfkb$1di3b$1@dont-email.me> |
| In reply to | #37394 |
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
[toc] | [prev] | [next] | [standalone]
| From | c186282 <c186282@nnada.net> |
|---|---|
| Date | 2025-12-10 05:29 -0500 |
| Message-ID | <JzCdnUQVx_nm1qT0nZ2dnZfqn_GdnZ2d@giganews.com> |
| In reply to | #37403 |
On 12/10/25 04:47, The Natural Philosopher wrote: > 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 It can be good for some stuff, alas not IP cams and other higher-bandwidth devices. Hmmm ... maybe 300 Hz ? Goes everywhere ! >> 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. IMHO it barely matters ... if you have a router/AP then you can link extenders. Those can, cheaply, deal with certain blank spots in the wifi coverage. >> 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. "Bars" ??? How CRUDE ! :-) I wanna SEE colors on the walls. Maybe next year. Hmm, just found an article about new quantum tech to finely analyze 5+ ghz comb signals. > 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 ... 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. MIGHT be some bridging fixes less odious. Have to research that further. 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 ....
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2025-12-10 11:29 +0000 |
| Message-ID | <10hblhu$1di3b$25@dont-email.me> |
| In reply to | #37410 |
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
[toc] | [prev] | [next] | [standalone]
| From | Daniel James <daniel@me.invalid> |
|---|---|
| Date | 2025-12-10 13:01 +0000 |
| Message-ID | <10hbqv5$1gdcg$1@dont-email.me> |
| In reply to | #37410 |
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.
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2025-12-10 13:05 +0000 |
| Message-ID | <10hbr62$1gt1t$1@dont-email.me> |
| In reply to | #37416 |
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)
[toc] | [prev] | [next] | [standalone]
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
Back to top | Article view | comp.sys.raspberry-pi
csiph-web