BeagleConnect projects

Hey GSoCers…

We are working up ideas on how GSoCers can help the BeagleConnect project. I’ve just posted a number of updates at BeagleBoard/GSoC/Ideas-2022 -

I appreciate any feedback/questions.


Please, please, please update your ideas NOW. Google will be look at the ideas page any time and the quality of this page is often cited as the #1 factor in being chosen to be a mentoring organization.


Please ask questions now about the ideas page. You can do so here, Slack or on #beagle-gsoc on and #gsoc on


I hope to eventually bridge the Slack channel and Libera.Chat doesn’t allow double bridging.



I typed everything below before I jumped to this beginning.

This is the second start to the beginning.

  1. Is it safe to say that handling protocols over the radios is fool proof? What about security and safety of the device in question?

  2. I mean…is being able to not be intercepted an option? Can one, while sending over-the-air upgrades, feel safe as it having a connection singularly to the connection in question?

  3. I am not big in security but knowing is half the battle. And to think of this device, the cc1352, which to my knowledge brings in many different protocols to act on behalf of the user could be altering for many people to whom have had to lift feet instead of fingers.

  4. Anyway, if it seems like I am braggin’ just a bit, it is not because of me. I just enjoy putting things together and when it is done well, well, one would have to notice.

and…one more.

  1. Will this be as simple to use as say a M4 MCU or will this be some heavy weight learning that needs to take place to advance in such a sum of multifaceted protocols?

I am not a person of interest here but I want to help or not help if chosen to not help. Odd? Just wait!

So, I went through the details, the older details, of the Beagle Connect project. I like it. I have umpteen questions involving this project. So, where to start?

  1. Firstly, does the BeagleConnect create a pathway introduction into handling over-the-air updates/upgrades to specific boards, am335x related, within the family of boards?
  2. Secondly, if so and if this over-the-air update/upgrade functionality works or is having a plan to work, does this entail sending WiFi enabled boards in the near or distance proximity this functionality?
  3. Thirdly and the kicker, once this effort is in place and completed, can one with the hardware already attached update the kernel, userspace, and source for hardware over this protocol(s)?

I am asking because I am learning slowly of this project and wanted to learn more and more and…

So, this is neat. Instead of having the task of handling hardware in field related scenarios, attachments can be made and then when in the proper limelight, one can proceed to handle the radio device.

I want to account for this being real. I think it is real. It is a nice idea to be able to handle things in alone time while not having stress-field related tasks at hand. So, deliverables and then procedures of source without daunting the fields of glory.


P.S. If my questions are too broad and not technical enough, please, and this is to anyone, chime in and let me know what exactly needs to be answered. Processing things and taking time works in theory but when deadlines are at hand, things get awkward and fun! I will keep asking things as I see fit but if are like me and dislike deadlines, chime in anyway please. I would also like a general consensus on how things are being handled. I am Seth and I am not affiliated but a fanatic, i.e. if there is such a thing.

I think this is for students and GSoC people. Excuse me for belching my questions out. I am fully embarrassed now. Anyway, if any of the students would like to shine some light on these questions and have permission, please be my guest.

Not at all fool proof. We’ve been running 802.15.4 on the SubG bands for a couple of years reliably. That doesn’t mean there aren’t any lurking issues.

There are encryption layers that aren’t turned on. The goal is to out-of-box provide a WPS-like key exchange and enable USB provisioning of keypairs as an upgrade path. This hasn’t been implemented.

Not without setting the device keypair. For now, OTA updates haven’t been enabled.

uh, ok.

uh, ok.

It is an M4 MCU. I started trying to build a toolchain to simplify starting with Zephyr. Robert is putting it into the “mikrobus” test images. We’ll be updating the readme once that is done.

We had a student look at adding Micropython to make it easy. Other programming options are likely to follow.

No. It targets MCU boards to expose their interfaces and data collection to any Linux computer running the right services.

No, it uses its own wireless protocols, not WiFi. It is not for the purpose of OTA updates, but instead the collection of sensor data and control of actuators.

What are you saying? What is a field in this context?


Oh. About the field work that I was trying to relay into the mix of things…

So, instead of having to actually go about to the device constantly for work, one could basically sit, work, and send. Then, on the receiving end, “one could enjoy the work being done without error of device manipulation.” Actual, device manipulation. For instance:

  1. Faulty joints in the field from soldering and reworking, i.e. hardware stuff.


P.S. I was not expecting you to answer at all or so quickly for that matter. Thank you. Sorry for the follies making you say, “uh okay,” about the security concerns but it is a hot topic right now in life, computing, and in general. People do not want their machines altering themselves to their knowledge. I am sure, no pun intended, there are already algorithms for this matter. It is a fine time to be in computing! Okay, I have had my fun. I cannot wait to see what everyone else had for this matter!

Hello Sir,

For anyone using the BeagleConnect and trying to promote findings, here are some good starter ideas:

  1. Arm Cortex-M Developer Guide — Zephyr Project Documentation
    a. This link should bring you passed the Getting Started section(s) and allow for understanding what is available and what is not available on the Cortex-M (ARM v7-M) processor located on the Connect.

  2. It also seems that the QEMU builds are only for Cortex-M3 builds and not for the Cortex-M4 builds. Please correct if I am wrong.

  3. For flashing instances, and again from the Zephyr docs. pages, Flash & Debug Host Tools — Zephyr Project Documentation shows some .dts fragments for how things should be allocated in such a file.

Anyway, I will be making more time available soon for this product instance. If you are using this product to create host (BBGG) to target (Connect) procedures, please try to give and take a bit.

Communicating and/or sending in specific instances of advancement may prove useful.


P.S. I am reaching out to see if people are onboard w/ this flashing, building, and development of the Connect. If you are and if you are holding back to find things out for yourself, okay. But please, making tasks portioned in b/t different people can help. For instance, person one could be working on A while person two can be working on B. That is all for now.

@jkridner ,

Seth here. Um, do you think this is a plausible thing to scour to find advancements in the BeagleConnect ideas?


P.S. I contacted the fellow to let him know I would be watching. Spooky! Anyway, outside of double trouble and stranger danger, I should be able to get back to the ideas surrounding these builds soon. I fell off. I am sorry.

I forgot to send in the link: general: Added ability to use SimpleLink with Zephyr API by ubieda · Pull Request #30 · zephyrproject-rtos/hal_ti · GitHub is a pull request I found lately that has to do w/ a SimpleLink from TI and his ideas based around porting STM chips to the ideas.


Also… @jkridner :

  1. Are the combination of BBGG + BeagleConnect supposed to allow for upgrades over the air via another board from
  2. For example…
    a. I had a USB to the BBGG from a host and USB to the BeagleConnect from the BBGG.
    b. On a totally separate host away from the Host + BBGG + BeagleConnect, I had a BBGW plugged in via USB.
    c. This BBGW was able to sync and update/upgrade the BBGG from the other host in a separate location.

I did not test the length in meters/yards for being able to acquire this signal, i.e. mostly b/c my quarters are small.

But…is this actually supposed transpire?

I have not gained a ton of knowledge on this front yet. I am still reading while I am available. Summer is around the corner!

Any Linux computer + BeagleConnect Freedom should act as a gateway to the SubG network. Once we get over-the-air updates working, any Linux gateway should be able to act as a host for firmware updates.

There’s no need to perform an over-the-air update of a BeagleConnect Freedom that is connected to a Linux host. There is a simply Python script for updating the firmware over USB as used in the existing flashing instructions.


Thank you for replying. Got it. I figured something was up, i.e. as though I conquered space and time. It was odd for me at first. NO over-the-air upgrades of the BeagleConnect Freedom. The Python scripts handles it. Understood. Okay, just like in the builds online.


P.S. B/c of my lack of oomph and total laziness, I have gotten into my 3D World again but not w/ the RepliCape. Just an update here. So, back to the standard(s) and looking for clues. Gasp.

@jkridner and to Anyone Reading This Idea(s) ,

Hello Sir, I am sure people are super busy now. GSoC is probably making more stress/fun on people enjoying their time teaching/learning outside of my insignificant issues but!

Here is goes:

I am readin’ the ole standard now. I am slowly turning into a repetition giant here.

  1. Is the WPAN section to the Beagle Connect already done, i.e. as I am trying to realize what is done versus what may need to be conquered?
  2. Are the conversations going on to make it known how to converse as a group on this multi-protocol idea?

I am really trying to figure out where I can fit in right now on this building of source for the Beagle Connect.

It seems like not many people, mostly b/c of their lack of knowledge on me or b/c of GSoC now, are forfeiting info. generally to me. I am out of the loop.


P.S. I have not plugged in for some time, i.e. as I am trying to know the standard and get to know what needs to be accomplished outside of what others are doing. For instance:

a. Does Mike know that things are already done with WPAN?
b. Is Mike working on signal integrity b/c I was working on signal integrity.
c. Maybe, for reference, I could be directed to a specific portion of the standard to learn to get well-rounded with it instead of rereading over the same sections thinking I could use them in the future.
d. Also, being needy here, I would like to know where to compartmentalize my readings. For example, I can learn different things about the Connect, the standard, and the protocols behind it all but I need direction.

I feel like I am reading without warrant right now.

If this is coming across as aggravated, it is. Just kiddin’. I am not so aggravated but lost right now in this build of the Connect w/ source support. Sorry. I am reaching out to get direction, to reserve time for specifics, and then produce on the specifics.


To anyone using the commands to make the BeagleConnect work thus far, are you doing okay w/ the commands?

Odd question? Yes. I am asking in this manner b/c I am resulting in an error that I cannot get past as of now.


west zephyr-export
FATAL ERROR: command exited with status 1: /usr/bin/cmake -P /home/debian/bcf-zephyr/zephyr/share/zephyr-package/cmake/zephyr_export.cmake

Now, I am sure it is as simple as a new cmake but which one?


P.S. Also, if anyone knows of a working example, pitch in.

It is still in private beta. Best to ask on the Slack channel.

1 Like

BTW, the beagle feeds have had the necessary updated cmake in them for some time on the Bullseye builds.