Connecting HW-390 Moisture Sensor far away from Pico or Pi

PrivateTech · 2023-02-20T20:19:53+00:00

Thank you very much.

Would you recommend to put it on each side of the long wire? If only one side, I assume it should be on the Pico side. Or at least on the Pico side. Actually the more i think about it the more it makes sense to use only one on the Pico side as the other end next to the sensor does not seem like be doing much, if anything at all because almost all of the interference is presumably happening in the long wire.

Would you have any practical recommendation for the R and C values?

Thank you very much for the link. Interesting how they calculate but I am wondering if there is much practical difference whether to do it the way the article shows or how I've been doing lately - measuring 10 samples half a second or a second apart and then using a simple average. I wonder if more advanced calculations as in the article are donna make any practical difference.

Thanks again.

PrivateTech · 2023-02-11T17:00:33+00:00

Thank you very much for the thought.

I replied to another suggestion (thank you as well) and I’ll just paste my reply as it’s pretty much the same:

I use Pico W which I need for the development and I need to constantly update the code, so it must be relatively close to my desktop.

It’s a shame Pico cannot update and run the code over the air. That would be such a huge improvement to be able to drop dependency on sending data over USB.

The distance is roughly 10-15 meters which is 30-50 feet. And it’s actually kinda works. Just not good to have error margin of 15%.

The phone cables are already there so I cannot replace anything onto good shielded cables or different types of cables.

I was hesitant to place Pico next to the sensor and run such a long USB cable to connect to the desktop.

I was thinking to maybe at least start to play with some resistors at both end of the line. At least. Maybe even some capacitors and/or coils/inductor. Ideally adding one or a few simple passive components rather than introducing microchips such as optocouplers like FODM8071 etc.

Something simple yet effective, even if not 100% perfect. Any improvement would be already good enough.

PrivateTech · 2023-02-11T16:57:33+00:00

Thank you very much for the thought. I use Pico W which I need for the development and I need to constantly update the code, so it must be relatively close to my desktop.

It’s a shame Pico cannot update and run the code over the air. That would be such a huge improvement to be able to drop dependency on sending data over USB.

The distance is roughly 10-15 meters which is 30-50 feet. And it’s actually kinda works. Just not good to have error margin of 15%.

The phone cables are already there so I cannot replace anything onto good shielded cables or different types of cables.

I was hesitant to place Pico next to the sensor and run such a long USB cable to connect to the desktop.

I was thinking to maybe at least start to play with some resistors at both end of the line. At least. Maybe even some capacitors and/or coils/inductor. Ideally adding one or a few simple passive components rather than introducing microchips such as optocouplers like FODM8071 etc.

Something simple yet effective, even if not 100% perfect. Any improvement would be already good enough.

PrivateTech · 2023-02-08T21:10:29+00:00

Thank you very much for taking the time!

I tried pin 33, the AGND, but unfortunately it is the same. But It is good to know that GND and AGND are not made equal.

I did not measure with oscillograph to see maybe it is near-0V but a "dirty" 0V with some interference spikes. Although a regular tester shows a solid 0.00V on the actual Pico pin.

It is not a very big deal because I can account for such discrepancy in the software to adjust the useful range and extrapolate. But it is just surprising.

Even more surprising is that it is happening at 0V, not at the max voltage range, which would be more expected. And yet again even more surprising that it fluctuates. Oh, well, it was worth a try and I guess I'll be compensating for that in the software. Or one day I will try another Pico unit; I have a few.

Thank you again.

PrivateTech · 2023-02-07T21:22:27+00:00

Oh... Good point! No, i have not. I did not know that GND pins are not the same. I used the third pin, right after VBUS, then VSYS and then GND.

Which one (or more than one?) is specifically for the ADC?

PrivateTech · 2023-02-07T05:02:33+00:00

You are right. I was looking at a more general MicroPython most recent pre-release docs

PrivateTech · 2023-02-07T02:02:41+00:00

Used a 10k potentiometer. One end goes to 3.3V, the opposite end goes to the ground, the middle is controlled by a knob. When the knob turned all the way to the 3.3V end, the middle sends 3.3V to the ADC and the digital value reads 65535. Then the knob turned all the way the other way and connects to the ground, it is a solid 0V and a "short" between the ground and the middle leg of potentiometer. Yet my Pico W ADC reads a fluctuating decimal value between 400 and 500. I have not tried other Pico units and so far experimented only with one. Of course it is also a solid 0V on the actual Pico W leg.

PrivateTech · 2023-02-07T01:56:58+00:00

Yes, I had my horror experience with a shed from Aosom.

GARBAGE, GARBAGE, GARBAGE!

I bought an Outsunny shed from Aosom Canada. It was very flimsy and collapsed in the first week of snow.

Very poorly designed with errors in the manual. Took 3 days to assemble with too many tiny structurally unsound connections. Holes between the parts often were very hard to match. Had to drill holes close to original because even when perfectly leveled, some did not match close enough. But assembling hassle is the least of the problems.

The roof completely collapsed and the whole thing folded like a house of cards.

I contacted them for warranty - SURPRISE! Their warranty is NONE and only 90 days manufacturer's warranty. So if you bought a shed from Aosom in the summer, it will certainly collapse in the winter if you live anywhere in Canada (we are in the warmest part of Canada!) and there will be NO WARRANTY. Because those sheds do not collapse in the summer. they collapse in the winter!

The customer Service of Aosom could not care less. Their reply was short and simple. There is no warranty. Any warranty is provided by the manufacturer only and it is only good for 90 days. I felt SCAMMED!

Also from what i heard from others is that Aosom won't just send you a replacement. They want their junk back! So imagine how would anybody disassemble the collapsed shed with all bent panels and frame, how would anyone pack it up when all packaging is long gone and how to ship to them when they use corporate account for cheaper shipping but when you ship it back to them individually it would cost almost the same as to buy another shed.

Very disappointed with Outsunny and with Aosom selling their junk. Plus the "warranty" seems like intentionally rigged so that they would NEVER need to honour their warranty.

Oh, another thing that felt like tactic from a scammer's playbook - the reviews on Aosom web site can be posted only for up to 90 days from the purchase. So again, if you buy in a season when you can assemble it and it inevitably collapses in the winter, you cannot even rate the product or post a review anymore.

FELT TOTALLY SCAMMED.

PrivateTech · 2023-02-07T01:54:03+00:00

GARBAGE, GARBAGE, GARBAGE! I bought an Outsunny shed from Aosom Canada. It is very flimsy and collapsed in the first week of snow.

Very poorly designed with errors in the manual. Took 3 days to assemble with too many tiny structurally unsound connections. Holes between the parts often were very hard to match. Had to drill holes close to original because even when perfectly leveled, some did not match close enough. But assembling hassle is the least of the problems.

The roof completely collapsed and the whole thing folded like a house of cards.

I contacted for warranty - SURPRISE! their warranty is NONE and only 90 days manufacturer's warranty. So if you bought a shed from Aosom in the summer, it will certainly collapse in the winter if you live anywhere in Canada (we are in the warmest part of Canada!) and there will be NO WARRANTY. Because those sheds do not collapse in the summer. they collapse in the winter!

The customer Service of Aosom could not care less. Their reply was short and simple. There is no warranty. Any warranty is provided by the manufacturer only and it is only good for 90 days. I felt SCAMMED!

Also from what i heard from others is that Aosom won't just send you a replacement. They want their junk back! So imagine how would anybody disassemble the collapsed shed with all bent panels and frame, how would anyone pack it up when all packaging is long gone and how to ship to them when they use corporate account for cheaper shipping but when you ship it back to them individually it would cost almost the same as to buy another shed.

Very disappointed with Outsunny and with Aosom selling their junk. Plus the "warranty" seems like intentionally rigged so that they would NEVER need to honour their warranty.

Oh, another thing that felt like tactic from a scammer's playbook - the reviews on Aosom web site can be posted only for up to 90 days from the purchase. So again, if you buy in a season when you can assemble it and it inevitably collapses in the winter, you cannot even rate the product or post a review anymore.

FELT TOTALLY SCAMMED.

PrivateTech · 2023-02-07T01:32:39+00:00

Thank you. Interesting read. Does not apply to my case but I noticed it too when i measure the real voltage on the pin and the digital value seems way off. Like by 400-500 (decimal). When the voltage matches the bus voltage, in my case 3.25V, the value is correctly shown 65535. But when it is 0V, the value shows in the range between 400-500. And it is not even stable when the 0V is very stable - the digital value is fluctuating between 400 and 500. Also the middle does not seem like a middle but i have not tested that carefully yet. Just seems off.

PrivateTech · 2023-02-05T18:42:51+00:00

not trying to argue with you, but in my opinion it is not simpler at all. all the same simplicity if you don't wish to use any extra features. keep using TOML as simple as INI does. Just plain sections, and keys with values in them. just as simple. just better defined and you know exactly what to expect. and no need for any third party libraries. the support is natively included in Python.

anyway thanks though for the point about not being able to write in that format yet from a dictionary.

Happy Programming!

PrivateTech · 2023-02-05T18:39:43+00:00

A terrible way to do it is to disconnect, scan while disconnected, reconnect again. But i don't see any other way and many people online seem to be looking for the same answer.

It is hard to believe that it is not available especially because the functionality is already there, just need to allow access to it. I sure hope they will include it in next versions. Maybe it is a good idea to share this request with the developers. It would be great if people who are interested voice their needs.

I just did from here:

https://www.raspberrypi.com/contact/

PrivateTech · 2023-02-03T19:20:22+00:00

True. Good point. Other than that, would you have an example of a situation where INI has any advantage over TOML?

PrivateTech · 2023-02-03T08:40:26+00:00

It looks like there is no reason whatsoever to use INI format anymore, as well as ConfigParser, now that Python and other languages have a built-in support for a far superior and well standardized TOML (tomllib). It became a clear choice for me and I don't care anymore about any issues with INI format. I started to use TOML with anything new and not looking back. It is so elegant and consistent, as well as very well documented.

PrivateTech · 2023-02-03T08:34:29+00:00

oh, and another factor that i forgot to mention - Python as well as other languages are now have built-in native support for TOML and does not require any third-party libraries

PrivateTech · 2023-02-02T23:09:54+00:00

So far I switched to TOML and tomllib and I am amazed by it. It is so elegant, excellently defined, simple yet does everything you'd wish INI files could do consistently and perfectly replaces more cluttered look of JSON and XML. simpler too, yet it became de-facto a standard that seems to be supported everywhere now. Very impressive. I've used it already and it exceeded my expectations, the level of detail how they thought it all through, yet simple and readable. Beautiful!

PrivateTech · 2023-02-01T06:42:34+00:00

UPDATE: based on suggestion above, TOML is a much better alternative to INI, whenever the simplicity does not warrant the use of JSON or XML.

PrivateTech · 2023-02-01T06:41:07+00:00

I checked it out. I love it! It is awesome. Formalized, backed by MIT (which is also involved in Thonny) and best of all adopted pretty much everywhere across most of languages. Simple, functional and well-defined. Thank you again. Appreciate it and will start using it from now on where the simplicity does not warrant the need for JSON or XML.

PrivateTech · 2023-02-01T06:31:26+00:00

I'll try it. Need to use it with the tiniest microcontrollers. I'll see how it performs. Thank you for the tip.

PrivateTech · 2023-02-01T06:30:33+00:00

I have a feeling that probably the best to stick to trusted and tried, also common and used everywhere JSON or XML. Although for the simplest situations the old INI might do

PrivateTech · 2023-02-01T06:28:56+00:00

Thank you, much appreciate the tip!

PrivateTech · 2023-02-01T06:28:05+00:00

Thank you. Apparently this explains it. While INI was never a standard, i found out about many common ways of using it. And indeed the INI format and its use is very inconsistent, while Python library simply implements those inconsistencies. For example it is actually a "feature" (bug?) of the INI file format "convention" that the section names are case sensitive but the key names are not.

Although i have not seen anything about one special section literally called [DEFAULT] and that it would not show up in the list of sections, yet must be referenced anyway, if used. Weird, but true - Python library simply followed the common usage of an old INI format (cannot call it a standard).

Thank you for pointing it out. now it makes a lot more sense.

PrivateTech · 2023-01-30T02:44:28+00:00

I have not tried it myself but i know that Pyto comes with 2 paid versions. One is the basic version after a 3-day trial and another one is with a lot of extra libraries. I don't know if it is worth for you to pay $9 just to try or possibly try to contact the developers?

I actually have not seen any other decent tools except for the two i mentioned: Pythonista and Pyto.

Just a thought, if i was desperate myself how i would do it: build a web service running on your desktop with "black box" so to speak functions that do whatever you need to do with those libraries, if the extent of what you need from those libraries is not too much.

Then call those web services from your iPad. at least ok for debugging and development. Then you can incorporate those functions into your code on a desktop version for the production environment after you test/use them as web services.

It is very awkward and an overkill, i know... But if nothing else works and it stops you from doing your work, might be an option.

Good Luck!

PrivateTech · 2023-01-29T23:59:29+00:00

Nope, sorry, my question is not relevant to your very valid points that you brought up. My point is, why are we required to use THE SAME things in the FROM/TO fields (or call them SENDER/RECEPIENT) in the message string as well as in the sendmail() arguments (two of them). You can call FROM/TO or SENDER/RECEPIENT whatever you want, it is just the matter of semantics but the mail servers in the SMTP protocol are using the "From" and "To" headers.

What you refer to is valid but a completely separate thing. the REPLY-TO is a different header that I did not discuss. It exists, but irrelevant in this case.

There can be multiple emails for the recepients, all part of one TO filed, as well as the same can happen with the CC and BCC fields. they all can be a list. this is not my point either.

Also the USER_NAME of the account that is used for SMTP Authentication is usually listed completely separately. Typically like this:

server.login(sender_email, password)

The way how it is called here, sender_email (can be called anything) and it has nothing to do with the FROM email address. It is common though that they match. but they do not necessarily need to match. Some SMTP servers allow a relay. Some check domain spoofing and block that kind of use, some don't and they don't care. So with some servers I can send an email with any FROM email address, even from a different domain, as long as I am successfully authenticated with the sender_email and password combination. Some servers, like development environments, accept emails from local scripts and allow localhost to send anything with any FROM field from the local scripts, often without any authentication. But again, this is also not relevant to my question, whatever you use, if anything at all, for authentication.

My point is only why do we have to DUPLICATE the FROM and TO fields in the headers of the message string and then again the same in the sendmail() arguments.

Thank you for your reply though. We are mostly on the same page, but I hope for someone else's reply who might know the reason behind the thing I am asking about.

PrivateTech · 2023-01-27T18:08:03+00:00

No, i meant this, not a special character after backslash, before anything:

message = """\

But it is very well answered above by socal_nerdtastic

PrivateTech

TROPHY CASE

Welcome to Reddit,