Arduino Uno Q Preliminary Example

[TMRh20]

Adding preliminary example for Arduino Uno Q

[TMRh20]

The only main problem is the Arduino Q MCU output is not respecting the new lines, but other that that it works.

[2bndy5]

Arduino Q MCU output is not respecting the new lines

Doesn't seem to be our problem.

I noticed about a bunch of complaints about the App Lab proprietary software and the Uno Q board on Arduino forums. It looks like a lot of redit users got all fired up too, but I'm not re-posting that doom scroll.

If Arduino (Qualcomm) doesn't consider community feedback from the Uno Q roll out, then there might be an inevitable maker community exodus toward alternatives (probably PlatformIO + Zephyr project). But simplicity like the Arduino IDE experience is hard to find in alternatives.

[2bndy5]

What version of Python is running in the app lab?

If app lab is not using a venv for each project

python3 --version

[TMRh20]

I think it runs a venv for each project inside a docker container.

What version of Python is running in the app lab?

Python 3.13.5

[2bndy5]

Yikes! Using a docker container seems like overkill (especially for a SBC) if they want to protect the Linux system assets. Do you have to run App Lab with root privileges? This invokes so many other questions about using bricks. And I thought I over-thought things, damn.

[TMRh20]

No, root privileges are not required.

Turns out you can't just do things like create or access a TUN interface either, so that pretty much rules out any RF24Gateway like behavior too.

[2bndy5]

Yea, I just saw your arduino forums thread. Does app lab allow you to add custom args when running the docker container? If so, I suspect you could forward network ports into the docker container.

[TMRh20]

Does app lab allow you to add custom args when running the docker container? If so, I suspect you could forward network ports into the docker container.

App lab is pretty sparse for options etc. I was trying to figure out a way to run docker with CAP_NET_ADMIN privileges but still haven't figured out if its possible.

[per1234]

the Arduino Q MCU output is not respecting the new lines

Hi @TMRh20. I have notified the Arduino App Lab developers of the incorrect handling of the \n (LF) line ending by Serial Monitor.

Note that the Arduino App Lab Serial Monitor does handle CRLF line endings (which is what is used by Print::println) as expected. So it may be possible to work around the problem in some cases (though I understand that in this case where the line endings are in the library source code that would be inconvenient).

[TMRh20]

Something seems to have changed with the Q lately.

Running this example now results in what seems to be a hang of the MCU.

Changing this line to Bridge.notify("RF24Callback", encoded_details[i]); seems to work around the issue, but requires also adding a delay, because the notify function doesn't wait for an ACK.

I'm not sure if I want to change this right away or what. The google AI results indicate this is a 'known issue' and the same Bridge.call function seems to work in my advanced example at https://github.com/TMRh20/Sketches/tree/master/ArduinoQ/rf24-advanced-interaction

I think it might be best to wait to see if these Bridge issues are resolved before making more changes. Its not an RF24 issue, but some sort of timing issue or something it seems with the Q.

I don't like this board much after working with it now for over a month... I think the Raspberry Pi has it beat by many miles.

[2bndy5]

Maybe that example just needs to wait until the bridge is ready. I found an example in Arduino forums. The solution seems similar to waiting for while (!Serial); before emitting output.

[TMRh20]

I'll have to try that out later! Thanks for the tip!

[TMRh20]

Well I tried the workaround in that thread:

  while(!start)
  {
    Bridge.call("linux_started").result(start);
  }

It just seems to hang on this call, never syncing. IMHO the Uno Q has now reached the level of hokey and almost unusable.