Superp

Indeed, a Pi with HAT Brick, GPS, CO2, AirQ, sound pressure, multi-touch, segment display. One module is an adapter plate for external power packs. You click in a power pack and off you go. I really like that. Took a few experiments to get it right. Thanks for the info on CO2. Grüße!

Michael, Your project and explanation inspired me to add a CO2 sensor to my project, and is has been very interesting so far. With Covid-19 even more so, as an indicator of how much of the air you breathe is actually second hand. I put the whole thing on the table at a meeting, for instance. Quite graphic. Other discoveries are how little the CO2 ppm differ between city and countryside. Or that when you're sleeping, CO2 is relatively low, it starts to rise as soon as you wake up. As a portable device, it is almost like a sixth sense. I find CO2 levels at the high side (rarely below 1000ppm, outside or in), so will be getting a second sensor to compare.

Well no, I would not say it is fixed, it's documented. This is costing me a bit.

Hello, For a Master Brick 3.1 (HW version 3.0.0, FW 2.5.1, Ruby bindings 2.1.29), it seems #get_usb_voltage always returns 0 (zero). The documentation says "Returns the USB voltage. Does not work with hardware version 2.1". I am asking because I have a stack powered via USB by a power pack.

Since a few days we have a GL.iNET Mango setup as a second AP with a separate SSID serving only Tinkerforge stacks on 2.4GHz. The main router powers the Mango from one of its USB ports. Connections for both stacks have been stable for a few days with this setup. So it is indeed the Wifi extensions not getting along with the big ASUS router.

Because the blog has no possibility to comment, I'll respond here. Thanks for blogging again in English. It is good to have some insight into the supply problems, and to read about your plans. Looking forward to working with Tinkerforge – people, software, and hardware – in 2022. And...thanks for your patience in providing support!

We'll setup an alternate AP to test this. I will get back to you after the Christmas weekend.

I can confirm FW 2.1.6 fixes this issue for Wifi Extension 2.0 in client mode (with the limitation described above).

2.5.1 Beta FW fixes this on my Master Bricks.

Some new observations. First, I configured a stack as AP only, letting it create its own network, USB power-only. After 30 minutes, the stack was still responding normally via that dedicated network. Second, I re-configured the same stack as client only and hooked it up via USB to a Mac. It soon stopped responding on its IP address. It is then still possible to connect via USB/localhost, as I said. When I do, the Wifi status in Brickv still shows changes in Signal Strength. So the extension seems to still be running, but it no longer responds on the network. Third, I re-configured the same stack as client and AP, USB power-only. This has now been running for an hour. When I connect to the AP (dedicated SSID), the stack still responds. When I connect to the client (regular Wifi network), it times out. The problem seems to be specific for the Wifi client function. Let me know i you have any ideas.

Yes, as I said, both stacks have the same problem. Both extensions were part of the same order. The stacks are USB-powered, so I can't plug in USB after they become unresponsive. But when I connect (& power) via USB, the Wifi will become unresponsive as described, but the stack keeps responding via USB/localhost. I postponed any and all connections, including pings. If I have the time today, I will try to configure a stack: a) AP only, b) client+AP, and see what happens.

Same problem as originally described.

That is why I uploaded the image. The four rightmost contacts look like they have been hand-soldered, post assembly. There are also traces of heating visible on the board. The speck looks metallic. It is firmly stuck on the 5th pad from the right. [...] I scrapped it off, it is a tiny bit of metal. [...] Flashing the extension to 2.1.5 [...] Flashing the extension to 2.1.6 (!!) More to follow

Well, thank you for answering!! This issue was actually discovered two months ago by @duawand fixed by @photron within 24 hours with a patched version of Brickv which you can download there. That patched version works on Apple Silicon, and will flash your Master Brick. The discussion there is in German, and was apparently forgotten by the good people at Tinkerforge. To summarise: with the current stable version of Brickv, 2.4.20, on a computer with Apple Silicon (M1 etc.), when you put a Master Brick in bootloader mode, Brickv will not be able to flash it. The "serial port" drop down will be greyed out; you can not select your Brick. Unless you have an alternate computer available, like an Intel Mac, this means when you attempt to flash a Brick, it becomes unusable. I know of no documented way to exit from bootloader mode. People using recent Macs, be warned. The good news is the patched version of Brickv solves this.

Hello, I am having some trouble with two stacks, both becoming unresponsive when connected via Wifi. Last week I received two Master Brick 3.1's and two WIFI Master Extension 2.0's plugged the extensions each on top of a Master Brick connected each stack via USB, and in Brickv: configured the extension configured and saved Wifi reset unplugged the stacks and powered them up with separate power supplies Immediately, both stacks had the same problem (when I boot up just 1 of the stacks): They boot up and connect to WLAN At this point, they behave normally: They respond to pings (response <15ms) They can be discovered and used in Brickv They can be discovered and used via Bindings After some time (between 5 seconds and 10 minutes, approx), the stacks stop responding: each of the three methods above just produces timeouts To get back online, I have to reset the Master Bricks or disconnect/reconnect power. The most extreme case is where a stack booted, I ping'ed it, I received 3 responses and then only timeouts. Other times, a stack works normally for up to 10 minutes, then hangs. I have also tried postponing first connection for 10 minutes after booting. First connection after 10 minutes also results in timeouts, so the stack "hangs" by itself (?). The WLAN is otherwise stable and fast; the router is an ASUS RT-AX86U. Things I have tried: Fixed IP vs DHCP assigned IP Different power supplies Reposition stack in relation to router Configure different Wifi standards (b/g/n) No Bricklets attached vs Bricklets attached Connect from a different host (MacOS vs Pi OS) Reboot Wifi router Repeat init/config of stack from start While trying to solve the problem, there were distractions: I discovered the Wifi status LED behaves oddly. This issue is thought to be unrelated. Discussed here. I discovered the Master Bricks return unexpected values for chip temperature. Also thought to be unrelated. Discussed here. One of the Master Bricks died; it appears stuck in bootloader mode. Solution still pending. Discussed here. This is the dialogue Brickv produces when a stack times out: This is what happens when I ping a stack right after it boots, and again 15 minutes later. No connection attempts in between: m1:~ ping 192.168.1.41 PING 192.168.1.41 (192.168.1.41): 56 data bytes 64 bytes from 192.168.1.41: icmp_seq=0 ttl=128 time=92.117 ms 64 bytes from 192.168.1.41: icmp_seq=1 ttl=128 time=9.247 ms 64 bytes from 192.168.1.41: icmp_seq=2 ttl=128 time=6.411 ms 64 bytes from 192.168.1.41: icmp_seq=3 ttl=128 time=4.392 ms 64 bytes from 192.168.1.41: icmp_seq=4 ttl=128 time=5.195 ms 64 bytes from 192.168.1.41: icmp_seq=5 ttl=128 time=6.888 ms ^C --- 192.168.1.41 ping statistics --- 6 packets transmitted, 6 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 4.392/20.708/92.117/31.971 ms m1:~ ping 192.168.1.41 PING 192.168.1.41 (192.168.1.41): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 Request timeout for icmp_seq 2 Request timeout for icmp_seq 3 Request timeout for icmp_seq 4 ^C --- 192.168.1.41 ping statistics --- 6 packets transmitted, 0 packets received, 100.0% packet loss Let me know if you need more info.

Thanks for explaining in detail. This is certainly an interesting bug. To conclude, what happens next? There will be new firmware, or Now that we know what happens, we leave it as it is If you could clarify that? I propose we then close this threat and I start a new threat about the unresponsive stacks.

I know this is a long shot, but: My Master Bricks have a type of microcontroller that is supposedly a 1:1 replacement for a different type, but which turns out to be different in at least 1 very small detail: °C scale. When I combine my Master Bricks into stacks with Wifi extension 2, their Wifi status LEDs act weird, and the stack becomes unresponsive when connected only via Wifi. Probably just coincidence.

Thanks for your quick help and clarification. Since the units reported already vary depending on microcontroller, would it not be an idea to switch to 1/1 °C once and for all? I am eager to test the new FW, but as I already have 1 out of 2 Master Brick 3.1's stuck in bootloader mode, I must postpone this. I'll get back to you as soon as I can.

rtrbt, Thanks for your quick help. When I run your script, I get the exact same output. But after the green LED is switched off, it does not come back on again. Software reports the LED is ON, in reality it is OFF, until I reset or powercycle. To be sure: I reconfigured the extension in Brickv (extension 0 / WIFI 2.0) and configured it again as client only. I reset the Master Brick, and powercycled the stack. No change. Once off, it is not possible to turn the LED back on. I have two brand new stacks (MB3.1/Wifi2) that both become unresponsive after some time when connected via WLAN. I hooked up one stack via USB to be able to continue development, and then this problem with the Wifi status LED turned up. My thinking was, this LED problem is unrelated, but maybe it is not. Maybe whatever is making my stacks unresponsive via Wifi is also causing the problem with the Wifi status LED. The other Master Brick, while trying to address the above problem, entered zombie mode, as I reported here.

Hello, The documentation says #get_chip_temperature returns chip temperature in units of 1/10 °C for Master Bricks. I assume this is a typo, and it actually returns 1/100 °C.

Hello, I have a WIFI Master Extension 2.0 mounted on top of a Master Brick 3.1 As per the documentation I can control the green status LED of the WIFI Extension 2.0 with two methods: #enable_wifi2_status_led #disable_wifi2_status_led When I call the disable method, the led turns off, and #is_wifi2_status_led_enabled returns false, as expected. When I call the enable method, the led does not turn back on, but #is_wifi2_status_led_enabled returns true. Only when I reset the Master Brick does the green LED turn on again. Am I doing something wrong or is this a bug? (Edited to clarify #is_wifi2_status_led_enabled returns expected result)

Keeping erase pressed while plugging in USB does not make a difference. ioreg reports this: ioreg -p IOUSB +-o Root <class IORegistryEntry, id 0x100000100, retain 28> +-o AppleT8103USBXHCI@01000000 <class AppleT8103USBXHCI, id 0x1000002af, registered, matched, active, busy 0 (11925 ms), retain 115> | +-o IOUSBHostDevice@01100000 <class IOUSBHostDevice, id 0x100032648, registered, matched, active, busy 0 (265 ms), retain 24> +-o AppleT8103USBXHCI@00000000 <class AppleT8103USBXHCI, id 0x1000002ab, registered, matched, active, busy 0 (7757 ms), retain 103>

Hello, I am having trouble with a Master Brick 3.1, which I think is in bootloader mode: - while trying to solve an other problem, at some point "erase" and "reset" were pressed - none of the Brick's LEDs light up - Brickv does not recognise the Brick (it does recognise an other MB 3.1: same cable, same USB port) When trying to flash the Brick, it is not recognised either: Update/Flashing -> Brick -> Serial Port: "No Brick in Bootloader found" In other words, the Brick seems "dead". How can I revive it? (Brickv 2.4.20 on MacOS 12.0.1 on Apple Silicon) Any help is appreciated.

On Pi OS, most likely /var/log/brickd.log If you want to monitor, try tail -f /var/log/brickd.log in a terminal. Hit ctrl-C to exit. I have ordered a CO2 Bricklet 2.0, but it is taking its time.