"Brain" openag-device-software Q&A for PFC 3.0


Since @wsnook wins the “who will be the first person to submit a PR when the repo is public contest” I thought I’d start a few long running topics as a place to ask questions about the new code.

All the device side code is in the https://github.com/OpenAgInitiative/openag-device-software repo.

Ask away!


why the change to bbb from the pi?


Hi @bill-atx,

The beaglebone black is a much more stable single board computer. Yes, it costs about 2.5x what a rpi does, but it doesn’t corrupt it’s SD card. That is the main reason we switched. The BBB has a 4G eMMC that is super stable - even when you accidentally short GPIO pins. And if we ever do want / need more disc capacity, we can use the SD card for that.

Meet "PFC_EDU," the new PFC v3.0

@rbaynes, As I understand it, you’ll be busy this week with the Media Lab’s fall 2018 member meeting, so this is a question for when you have more time…

What is the procedure for signing a contributor license agreement? The CLA page on the wiki currently just gives a permission denied error.


I have two quotes for making the pcb and they seem high.
Seeed quoted 5856.78 for 5 populated boards.
Macrofob says 1802.57 for 5 populated boards.

Has anyone else received any better quotes?

There are issues with the bom as well, looking into that.


Cool. That answers my question too. Makes sense.


@bill-atx greetings as wsnook mentioned we are inundated with the ML’s fall Members’s week at the moment. I will create a thread which addresses the production of printed circuit board assemblies. Was the Macrofab quote of $1800 the total for the 5 assemblies included PCB fabrication and components or per unit cost?

I will also take a look at the BOM again to ensure nothing got mixed up with the files.


@Poitrast, these quotes are fully assembled turnkey with components and labor for 5 units.


This is the BOM issue:

The unselected parts are parts in the bom with no part number.


$360 a unit for 5 assemblies doesn’t sound too unreasonable given the relatively small batch; $1200 a board on the other hand seem way too steep. I will have to look into my quotes after members week, but off the top of my head I was getting sub $50 for assembly with slightly higher order quantities on a 10 day turn.


[edit: Please disregard the question I asked here earlier about thread locking. I see that Jake is already dealing with it in the type-check branch]


@bill-atx, I will go over you question more thoroughly on Monday, but many of the items on the attached list do not need components. For instance all of the TP parts are test points.


@rbaynes Do you know if your code will run unmodified on a BeagleBone Green or a BeagleBone Green Wireless? I’m not worried about possible mechanical interference with the additional USB ports since I don’t have a PFC_EDU circuit board assembly. I’m thinking more about low cost and the possibility of trying to implement a mult-I2C-slave device simulator on the PRU that’s common to all the Beaglebones.

More specifically, what I mean is, can you say with any certainty whether a BBG works, doesn’t work, or maybe works? I see stuff in the code that makes me suspect it might be sensitive to differences between BeagleBone boards. For example, I see lots of code that interacts with the BBBW wireless connection manager. Also, I see you have an is_bbb() function in device/connect/utilities.py that checks the contents of /etc/dogtag.


@wsnook Technically it is Jake Rye’s code, I just helped him with the I/O.

It has a good chance of working as is. I think the green uses the same build of Debian. None of us has tested a green. Jake develops on Ubuntu and I use OSX, both of which run the brain code in simulation mode.


Okay. Thanks for mentioning the simulation mode. I should take a closer look at that. I’m curious about how low of a level the simulation works at and whether it will enable test coverage for I2C drivers (stuff like water sensor temperature calibration, etc.).

Setting aside the difficulty of writing it, do you or Jake have any opinions about the idea of a PRU-based real-time simulator that could be programmed to respond on GPIO pins as a bus full of I2C sensors, actuators, and muxes? Making full state machines for all your I2C devices would be too hard, but perhaps something based on lookup tables of valid bit strings (e.g. set MUX + init sensor + stop, set MUX + read measurement + stop, etc.), canned responses, and simplified state machines could be workable. It seems like integration testing will be a big challenge as you add more devices and bus configurations to your ecosystem.


@wsnook check out the peripheral simulator idea. I think it comes close to what you are trying to do. Agreed on the state machines for each peripheral simulator being a lot of effort…probably more effort than it is worth right now. My simple solution for i2c testing / simulating was just to have a dict of stateless registers and write byte sequences with the corresponding read bytes being returned.

Regarding the PRU, my big hesitation with pursuing that development path is locking into a specific controller. Right now the only dependence is a unix system with i2c comms. Agreed on the challenges around integration testing.


@jake I looked at the simulator and the rest of device/utilities/communication/i2c. It seems like your basic strategy is to have the PeripheralSimulator and DeviceIO classes implement equivalent interfaces based on the read() and write() methods.

So far, my idea with the PRU is mostly a thought exercise about how to implement integration testing that covers both possible problems with lower level issues like threading and device drivers and also higher level integration tests. General thoughts:

  1. It would be nice to have a hardware test fixture that allowed people to cheaply and repeatably simulate a combination of sensors, actuators, and physical conditions. For example, there could be a test to simulate a temperature change and watch for a fan relay to switch.

  2. Threading with shared resources is hard to get right. What if the code ended up with two threads simultaneously trying to configure the mux and access different slave devices? How would those I2C bus accesses get interleaved? Perhaps the code is currently arranged so the I2C bus access is all confined to one thread, but maybe somebody will make a modification later that adds I2C calls on another thread. How can you test whether the locking is sufficient to protect mux settings and other state on the I2C bus?

[edit: I’m not asking for answers to those questions. I’m just saying that’s what was on my mind when I mentioned the PRU stuff.]


Gotcha, always happy to have more tests! I do like the case for evaluating control loop behavior. Being able to run them from a CI fixture would be a huge win, however I get that constraining all tests to be able to run via CI can be impractical…if this is something you are passionate about building, I’d love to check out a demo!


Okay. I’ll take a closer look at this. I think doing something good enough to implement automated pass/fail testing that includes control loops could be a fun challenge. No promises, but if I come up with anything good, I’ll let you know.


Sounds great! Make sure to check out the the test.sh script in the project root. On the type-check branch all tests pass.