Dude, you're hitting the limits of your understanding. That's frustrating, but it's also okay. So let's get at the root cause. Even better, if you're an embedded guy already (do you know how to set jump vectors? Are you practiced at the art of cross-compiling?), you've got all the tools you need and lots you won't.
I discovered a long time ago that I spent almost as much time reading blog posts and teasing out the relevant (and often, correct) bits as I would have just starting from scratch. In some cases, literal scratch. So if I were you, and I've been you, I'd do just that. Get familiar with... (drumroll please...) Linux from Scratch You can absolutely approach Linux like you would approach VXWorks or RTEMS or uC/OS-II.
Here is my own repo to get you started. Fire up that Vagrantfile, run the script as root, and an SD card image will magically appear. It won't be exactly what you need, of course, but it will be a good starting point for understanding how tutorials are sometimes broken and why dealing with distributions can have unexpected caveats. Once you grok how Linux really works in a "first, jump to 0x80000000" manner, you'll be well on your way.
The x15 is an official project of BeagleBoard.org, this is a BeagleBoard Compatible clone like the BeagleBone Green (software compatible, design files to be made public) designed by a commercial company called SanCloud.
To answer your question, the x15 Rev A failed FCC testing so they are working on Rev B.
Optos are a bit of an overkill. I use buffer ICs, essentially a logic gate that has no logic: Out=In, just sits between 2 devices. They can function as level shifters as well since the BBx outputs are <2V and some things need signalling of at least >=3V.
You'd want to use a relay mostly for switching very high/different power, separate-from-BBx's power like (household) AC, at low intervals (ie no flashing). And when using a relay the snubbing diode is required and an opto isn't such a bad idea after all. Otherwise a transistor/mosfet is all you want for DC.
Your method for wanting varying colour levels is not quite how that's done... There do exist digital potentiometers but this is not how to go about it.
Light dimming is usually done via PWM -Pulse Width Modulation- or super-rapidly flashing the colour channels at different rates for human-perceived dimming. BBx does have native PWM hardware. But here's a basic pseudo code for a brightness of 0-255 if you were to bit-bang it
function pwm(pin,brightness) { for i = 0 to 255 { if i < brightness then output[pin] = on; else output[pin] = off; } }
You most definitely do not want to use a relay on PWM as you will burn it out going so fast. A buffer or transistor will do. If your LED strip is the 12V 4-wire RGB[+12] then a mosfet is what you want, and the mosfets usually need >2V on the gate to turn on and off so you may also need the buffers or transistors in addition. Here's a guide using the arduino the circuit is essentially the same but note the arduino outputs 5V so it doesn't need an additional piece between the mCU and transistor
I'm no expert here, but it sounds like you need an electronic speed controller (ESC). In the past I've used a Turnigy Plush to control a brushless servo with a BBB. If the L6234 is your speed controller (I couldn't find this on HobbyKing), then you don't need additional parts.
PWM control uses square waves, not sinusoidal. You use PWM to control the ESC, which in turn takes care of controlling the brushless motor (I think the ESC generates the sinusoidal waves).
Before you can control the motor itself, you need to go through a calibration process of your ESC (range calibration). In the case of the Turnigy Plush, you would set your PWM to the value for max speed, then connect the power to the ESC (this will produce a beep), set the PWM to the min speed (this will produce a different set of beeps), and wait for a long beep (should follow the previous beeps). After the long beep, changing the PWM will effectively control the speed of the brushless motor. Before these steps, the motor would just not move when changing the PWM.
Again, I'm no expert and this is my experience successfully controlling a brushless motor with the BBB on a particular brand. The documentation on your hardware may provide more accurate instructions on how to calibrate.
I do have sample code on an old computer, but it will take me a while to dig it up. I based it on the code here, so you can use this as a starting point.
Let us know if this helps! Sounds like you have a very interesting project.
http://beagleboard.org/project/stache
Have you read this by any chance? Someone in the comment section had the same problem to yours. He found the problem to be OpenCV failing to detect the higher resolution of the camera.
Try the command 'v4l2-ctl -V' this should tell you the resolution options of the camera (and if your drivers are working)
This is probably the best advice. Unless there is a specific reason you need to use Angstrom, it would be better to switch to the official Debian distro available here: http://beagleboard.org/latest-images
The main reason I've found that makes the Debian distro better is that the commonly used Ubuntu distro is based on Debian, so when troubleshooting or installing compatible software, it is much easier when there is a ton of support available just a google search away.
I haven't tried Wheezy.
Are you using a custom image, or a Beaglebone demo image? I thought the capemgr would part of the demo images forever! :-o How are overlays loaded without the capemgr?
edit: So it looks like it's gone. At least there's https://github.com/cdsteinkuehler/beaglebone-universal-io. But, this really breaks the existing ecosystem of capes. I'm guessing the beaglebone demo images will keep capemgr and not upgrade until it's been ported. Such a moving target!
https://groups.google.com/forum/#!topic/beagleboard/gkVwuE7324U
http://stackoverflow.com/questions/17834561/duplicating-identical-beaglebone-black-setups
It's awesome that stackoverflow is getting a pretty good collection of beaglebone answers!
Reminds me of this: Monsieur
I was one of the backers for this. Obviously this is on a much larger/more expensive scale. Any thoughts on making a kit or product out of this? It would be fun to make.
Any thoughts on turning this into a kit or product? How much
Thank you for the comparison of version vs functionalities. As I can see (on https://stackoverflow.com/questions/40125182/how-to-make-newer-node-js-version-run-on-beaglebone-black-armv7-board) the version that is present in Debian 8.7 is v4.7.2, which is not "new" enough for the functionalities I want to achieve.
I have a question - do you recommend any specific installation guide, so that I can have the newest possible node on my BBB?
I believe the best way to use a LIPO with a PocketBeagle, is to use one of these.
https://www.amazon.com/gp/product/B08RRLWP67/ref=ox_sc_saved_image_3?smid=&psc=1
Connect the battery to to the pin of the PocketBeagle that can read the battery voltage. Connect the load coming out of this circuit to the 5v pin in the BeagleBone to feed power to the SBC. That way it can get power while its connected, and be fed from the battery when its not.
Neither driver seems to work for Catalina, and the PocketBeagle webpage claims they are only needed for previous images. http://beagleboard.org/getting-started
> Do I need to boot it from the microSD card? If so, then what is the source.
You need to make some effort. Beaglebone.org, click Beaglebone black, support, latest images, which takes you http://beagleboard.org/latest-images. There's are links to the image, a wiki, and to the beaglebone debian page.
> this really seems like a defective product...
What in the world makes you think this? You don't know what operating system you have on your super small Linux computer, or if it supports what you're plugging into it. That's the issue. The latest version of Angstrom (eww) or Debian should support it. The latest production image (made in March) should support it.
As the manual for that LCD states, they don't support the software side, which is the only problem you're currently having.
The Beaglebone and that LCD is a hobby project. Don't expect much hand holding, and you're already doomed with this attitude.
I don't know if the flash is faster than the SD card, but a wild guess would be that it is, but would be quite sized restricting.
http://beagleboard.org/black really is your starting point most times for finding resources. It links right to elinux which has the info for most distro support, including Ubuntu.
http://elinux.org/BeagleBoardUbuntu
To work with the BBB, you need the customized kernel, so what version Ubuntu will work depends on what version of the kernel is required (I believe?) Anyways it looks like they are dealing with Ubuntu 14.04.2 ( v3.14.43-ti-r67 kernel) now last updated 2015-06-11.
You usually flash the stock memory because of the updated uboot, but the black has always had a boot button and, with the proper flash loaded, the ability to boot from the flash or SD card.
I've used a couple USB wifi's with no problem, or extra work that I can recall, including a tiny Edimax usb thing.
That still makes me think it was copying itself from uSD to eMMC, that's exactly when you get that behaviour, but of course that can only be true if you actually had a uSD installed.
If you have a uSD card, I would recommend going to the beaglebone.org site and grabbing the latest release, and booting from that. There are two types of release available: working installs on uSD, and special 'flasher' installs on uSD that will actually upon first boot copy themselves over to the eMMC in a manner very similar to what you experienced.
There's a pretty good community, and even a "newbie" section of the forum, on the Beagleboard.org website - http://beagleboard.org/Community/Forums - and a number of great beginner tutorials under their "Learn" tab.
Mine does not have the web server running that the Angstrom has http://beagleboard.org/static/beaglebone/latest/Docs/images/bone101.png I just put in the flashable image to check and see.
It does have ssh setup on and running, 100% positive no could9. I wonder if they released an updated image with the webserver running after mine. What version are you using and where did you get it from?
Any 5V source should work... USB is a 5V source so I'm not sure why that isn't working for you, not to mention the BBB shouldn't ever really draw more than 500mA. This tutorial might be useful but I imagine you've probably read this already.
Hey I have made kiosks with Beagle and Pi before and my experience the GPU on the Raspberry PI is better for a dedicated system that requires X GUI applications. Avoid any of the Noob or pre-configured images.
What I've used in the past.
Other advanced options.
Find the COM port that your USB connection uses and put that into the Serial option. If you're on Windows, it will be in Device Manager under Ports. You'll have a few probably, try them until you get the one that works, or unplug and plug back in, and see which port is added when you plug in.
If you're trying to use an IP, you need to have the BBB plugged into the network, then probably do a netscan to find which IP on the network shows an SSH port open. That will likely be the BBB, unless you have other devices on the network that use SSH.
Yea, that's why I'm using a powered USB hub. It has an external 5V/2A power supply. This is the one I'm using: https://www.amazon.com/Protronix-Port-USB-Power-Adapter/dp/B00REX6DRK/ref=sr_1_6?s=pc&ie=UTF8&qid=1469733902&sr=1-6&keywords=powered+usb+hub
But it seems the problem is the fact that the power supply is non-linear, thus causing interference in the signal. The screen is powered and works just fine, but the touch functionality doesn't. Removing power from the USB hub causes the screen to stop displaying, but allows the wireless mouse to function.
EDIT: Also, it seems that data is also sent through the "power" connection. Plugging the "power" connection into an external power supply and the "touch" connection into the BBB still causes the screen to function, but not the touch functionality.
Early tests show that the RPi-2 is about 2.2 times faster than the RPi-B for a NAS server (15MB/s vs 6.7MB/s).
The RPi-2 is maxing out the 100MB/s Ethernet LAN, and people are looking at USB Gigabit LAN adapters.
These are early tests. I haven't gotten my hands on a RPi-2 yet to verify them.
Does anyone have any real numbers for how fast a NAS server on the BBB is?