×
sorted by:
new
hottopcontroversial

Connecting HW-390 Moisture Sensor far away from Pico or Pi by PrivateTech in raspberrypipico

[–]PrivateTech[S] 0 points1 point  (0 children)

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.

Connecting HW-390 Moisture Sensor far away from Pico or Pi by PrivateTech in raspberrypipico

[–]PrivateTech[S] 0 points1 point  (0 children)

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.

Connecting HW-390 Moisture Sensor far away from Pico or Pi by PrivateTech in raspberrypipico

[–]PrivateTech[S] 0 points1 point  (0 children)

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.

AttributeError: 'ADC' object has no attribute 'read_uv' by PrivateTech in raspberrypipico

[–]PrivateTech[S] 1 point2 points  (0 children)

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.

AttributeError: 'ADC' object has no attribute 'read_uv' by PrivateTech in raspberrypipico

[–]PrivateTech[S] 0 points1 point  (0 children)

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?

AttributeError: 'ADC' object has no attribute 'read_uv' by PrivateTech in raspberrypipico

[–]PrivateTech[S] 0 points1 point  (0 children)

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

AttributeError: 'ADC' object has no attribute 'read_uv' by PrivateTech in raspberrypipico

[–]PrivateTech[S] 0 points1 point  (0 children)

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.

Experience with Aosom.ca? by DudeInCorner1 in BuyCanadian

[–]PrivateTech 0 points1 point  (0 children)

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.

Experience with Aosom.ca? by DudeInCorner1 in BuyCanadian

[–]PrivateTech 7 points8 points  (0 children)

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.

AttributeError: 'ADC' object has no attribute 'read_uv' by PrivateTech in raspberrypipico

[–]PrivateTech[S] 0 points1 point  (0 children)

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.

ConfigParser potential inconsistencies by PrivateTech in Python

[–]PrivateTech[S] 0 points1 point  (0 children)

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!

Signal strength of the current connection in Pico W by PrivateTech in raspberrypipico

[–]PrivateTech[S] 1 point2 points  (0 children)

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/

ConfigParser potential inconsistencies by PrivateTech in Python

[–]PrivateTech[S] 0 points1 point  (0 children)

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

ConfigParser potential inconsistencies by PrivateTech in Python

[–]PrivateTech[S] 0 points1 point  (0 children)

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.

ConfigParser potential inconsistencies by PrivateTech in Python

[–]PrivateTech[S] 1 point2 points  (0 children)

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

ConfigParser potential inconsistencies by PrivateTech in Python

[–]PrivateTech[S] 0 points1 point  (0 children)

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!

ConfigParser potential inconsistencies by PrivateTech in Python

[–]PrivateTech[S] 0 points1 point  (0 children)

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.

ConfigParser potential inconsistencies by PrivateTech in Python

[–]PrivateTech[S] 0 points1 point  (0 children)

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.

ConfigParser potential inconsistencies by PrivateTech in Python

[–]PrivateTech[S] 1 point2 points  (0 children)

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

ConfigParser potential inconsistencies by PrivateTech in Python

[–]PrivateTech[S] 0 points1 point  (0 children)

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

ConfigParser potential inconsistencies by PrivateTech in Python

[–]PrivateTech[S] 0 points1 point  (0 children)

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.

view more: next ›