The ADC is one of the most useful parts of the BBB, but unfortunately there
is not a lot of support documentation in terms of working examples. I have
a few questions, and would appreciate getting some clarity on them.
a) What are some good examples of using the BB-ADC with or without PRU
intervention? It would be nice to see examples of high-rate continuous
capture and also regular low-rate captures. Just for context, 100Ksps is
high for us and 50Sps is low.
b) Is the BBB-ADC capable of synchronous (simultaneous or near
simultaneous) multichannel capture? If we really lower the rate requirement
down to 50-100Sps, can we THEN do multichannel data acquisition? Are there
code examples for multichannel capture at any rate?
c) If the answer to b) is "No", what would be the way to do a fairly
low-rate, sequential multichannel capture i.e., in a round-robin fashion.
Any examples of this type of capture?
The ADC is one of the most useful parts of the BBB, but unfortunately there is not a lot of support documentation in terms of working examples. I have a few questions, and would appreciate getting some clarity on them.
Check out the libpruio docs. It’s not the official solution, but the most powerful, used in lots of projects all over the world. It supports ADC up to 200 kSps. Faster ADC seems to be possible, but not in real-time. libpruio is designed for closed-loop-controllers.
a) What are some good examples of using the BB-ADC with or without PRU intervention? It would be nice to see examples of high-rate continuous capture and also regular low-rate captures. Just for context, 100Ksps is high for us and 50Sps is low.
Find examples in chapter “Examples”. Adapt and compile the source to any sampling rate or channel configuration meeting your needs. Supported languages: C, FreeBASIC, Python.
b) Is the BBB-ADC capable of synchronous (simultaneous or near simultaneous) multichannel capture? If we really lower the rate requirement down to 50-100Sps, can we THEN do multichannel data acquisition? Are there code examples for multichannel capture at any rate?
The TSC_ADC_SS has a multiplexer for 8 channels [0-7]. On BBB channel 7 is hard wired to the board power. Only 7 channels are available for custom purposes. Switching between channels needs a minimum of 15 cycles@24MHz, but you’re free to add further delay cycles. libpruio provides a standard configuration, but also supports full access to the sequencer steps. It also provides full access to all hardware registers (experts only). This features get handled form your source code. No need to adapt boot files, no reboots necessary.
Thanks, TJF. This is a little world in itself, which we are slowly digesting. Some very neat engineering there. I would have loved to discover this on a Google search some 2 years back. Dunno why it did not show up when I searched for PRU controlled ADC in the past. I will get back with more questions either here or otherwise as we stumble on our goal with these new tools!
Thanks, TJF. This is a little world in itself, which we are slowly digesting. Some very neat engineering there. I would have loved to discover this on a Google search some 2 years back. Dunno why it did not show up when I searched for PRU controlled ADC in the past.
Yes, it’s a shame. Very low support on this forum. Even my project page got robbed. Jason is now the owner, and I cannot update it any more. Most people get info from other forums ie. like hackaday.com.
So see it as an insiders tip.
I will get back with more questions either here or otherwise as we stumble on our goal with these new tools!
That’s funny TI has some of the best support in the industry especially if you’re a customer using the chips and the documents are easy to find.
I see a lot of very basic questions being asked in here and if I was a hiring manager I would Not hire anyone that didn’t even have the skills to find example code. I suspect they want their names to be seen in here and want some basic reading material to bluff through a technical interview. It’s shoddy psuedo engineer’s like that the caused people to be Killed on Boeing 737 max software outsourced to sub standard engineeers I know I worked with them lots of nodding and smiling no substance.
On Fri, 5 Jul 2019 16:41:40 +0000 (UTC), "'Mark Lazarewicz' via
BeagleBoard" <beagleboard@googlegroups.com>
declaimed the following:
It's shoddy psuedo engineer's like that the caused people to be Killed on Boeing 737 max software outsourced to sub standard engineeers I know I worked with them lots of nodding and smiling no substance.
From what I've read, some test bed software, and maybe some display
software was outsourced. NOT the flight management software -- which has
been produced by GE Aviation (formerly Smiths Aerospace, nee Lear-Siegler)
for quite some time on the 737. {I supported the "BootROM" of the 737
flight computers for four years -- BootROM runs the memory/processor
self-checks, and determines which application (dataloader, flight
management, etc.) is to be started based upon external sensors (no
dataloader if the wheels are not on ground <G>). The flight software for
the boxes was produced in the cubicle farm on the other side of the
building from mine.}
The gist I have for this fiasco is that shoddy requirements were in
play -- defining the MCAS system to be a "transparent" addition to the
software (one description I've read describes MCAS as being meant to
compensate for the different lift characteristics of the MAX when angle of
attack varies. The MAX engines are so large that they are mounted much more
forward from the wing, and higher -- as a result, when not directly aimed
into the air flow (as in climbs), the engine nacelle created a lifting
torque in front of the wing. MCAS was supposed to counter that torque so
pilots "feet" the plane behaving the same as non-MAX 737 models. However,
MCAS relied upon single sensor (and apparently did not have left/right
redundancy) -- the multi-sensor configuration was "optional" on the order
form.
Because MCAS was supposed to be "transparent", pilots were not supposed
to need updated training. It was also added to the flight software in a way
to minimize how much of the flight software (most of which has been flying
for decades on 737 models) had to be re-certified...
Wow, Beiber. This is as close a dissection of the MAX-737 issue as I have read or heard anywhere. Sounds criminal to have not used redundancy in the sensors, especially in civil aviation with so many lives at stake on a trip. Human complacency takes over, I guess, when something works so well for so long. The lifting torque you mention was of the yaw kind or roll kind?
I should have said of the pitch kind or roll kind of torque. Reports seemed to say it nosedived, so sounds like the pitch kind. And if there was a little bit of both, that is an even more complex aerodynamic stability issue.
Well, if both engines are running at the same power, then pitch.
Add an engine failure, so one at max power, the other one a “drag”.
She is going to pitch, roll and yaw, all at the same time.
Now, it is time for both the pilot and the programmer to earn their salary.
On Sat, 6 Jul 2019 08:45:59 +0530, Venkatesh Vadde
<vvadde@gmail.com> declaimed the following:
Wow, Beiber. This is as close a dissection of the MAX-737 issue as I have
read or heard anywhere. Sounds criminal to have not used redundancy in the
sensors, especially in civil aviation with so many lives at stake on a
trip. Human complacency takes over, I guess, when something works so well
for so long. The lifting torque you mention was of the yaw kind or roll
kind?
PITCH (which is why the MCAS gets described as an "anti-stall" system).
The air-flow over the top of the nacelles tries to pitch the nose up --
increasing the angle of attack, increasing the pitch force over the
nacelles (feedback loop), leading to potential stall over the wings
themselves. MCAS is supposed to adjust trim tabs to counteract the upward
pitch -- and supposedly be unnoticed by the pilots trained on older 737
models. It was an assist-feature, not considered flight-critical -- without
it, pilots could manually adjust the trim, but this would have been an
unnatural adjustment relative to previous 737 models (there was one news
report of a pilot who knew this much of the MCAS system being a guest on
the flight deck when they encountered a similar condition -- he told the
actual pilots to shutdown some part of the system which let them regain
control)
I'd put the major fault on the bean counters putting cost savings ahead
of anything else: make the system transparent so pilots don't need to be
retrained; make it a "plug-in" module so only it, in isolation from the
rest of the flight management software, needs to run through certification
process; make the additional (purportedly non-critical) sensors optional so
airlines can save money by leaving them off; get the planes out the door
now rather than next year...
Most of this evaluation came from various web sites and the more
detailed news articles (rather than the short blurbs TV news gives).
Bang on, I think: bean counters trying to save the buck. Now they must be paying for it in lots of lost business and $100M in damages to bereaved families. Not that the compensation does any justice for lost loved ones. And in the end, far too much reliance on technology instead of human faculties. A clear case to put man more in the middle of business, less of the machines and reliance on them.
