Beaglebone Black switch monitors

Since I've swapped the BeagleBone on my project with a BeagleBone Black, I would like to benefit from the Black's on-board HDMI capabilities and be able to hook up an external monitor when I need to even though my system is presently working with the LCD7 cape. The problem is that there doesn't seem to be any capability for the BBB to "switch monitors" like for Windows PCs. From experimenting, having the LCD7 cape connected to the BBB (which works) prevents the image from being sent to the HDMI port. If I disconnect the BBB from the LCD7 then when the BBB boots it can connect to an HDMI monitor fine. So far what I think I have learned is that the issue has to do with screen resolutions. It has been hinted on some forums that cape HDMI adapters are essentially monitoring the same signals that are used to generate the HDMI on-board the BBB, and there is no way to "switch" between them as a result. It has also been stated that screen resolution can only be set at boot time for reasons that I don't quite follow. The LCD7 has a resolution of 800x480, which is rare for most other monitors. So what seems to be happening is that during boot, the LCD7 is being recognized and the HDMI resolution is being set accordingly, and either the step for retrieving monitor resolutions from devices connected on the HDMI bus is not happening or the connected monitors would show an image if they supported 800x480. If the latter possibility could somehow be verified it would at least prove that the HDMI connections are in fact parallel. In any case, here is the documentation so far of my research into how this works:

Here is a thread which starts off with somebody having a problem with the BBB just outputting an HDMI signal, despite trying mixing various combinations of known good monitors and cables. Somebody asks the question how to force a particular resolution. Gerald has people try different OS releases, which doesn't work for some but for some people it fixes the problem. One guy turned out to have a bad HDMI adapter cable despite initially thinking that his cable was good. It turns out that bad cables are a huge cause of problems with BBB HDMI not working. Some people report having success with using HDMI to DVI adapter cables. There is a discussion of a configuration information called EDID, and forcing the resolution using the uEnv.txt file. There's a fbset command and a xrandr command. It is proposed to troubleshoot the problem by forcing resolution to 640x480@60 which apparently "all displays are required to support." One guy gives a gorgeous example of using xrandr to read info about the connected display, parse-edid to get info on the monitor, ID.txt file to get info on the OS, xrandr to set a new resolution and fbset for something. Then there is a discussion with a guy who has two BBBs with one that isn't working, but his problem is solved by reinstalling his OS on the board that's giving him trouble. Amazingly, this guy gets responses from Robert C. Nelson himself with this issue!
https://groups.google.com/forum/#!topic/beagleboard/0fMTXLPuGS4

A lot of the hints from Gerald and other users on the various google group threads that I've found are (uncharacteristically) well-summarized in this wiki page, which shows how to use xrandr, parse-edid, and how to mdify the uEnv.txt file: http://elinux.org/Beagleboard:BeagleBoneBlack_HDMI

Here is a google group thread where somebody asks exactly the same question that I have about running an LCD cape and HDMI video output at the same time. Except his case is slightly different in that he's trying, optimistically, to design an LCD cape of his own. He is also using Ubuntu which apparently has the HDMI output always on. This is the thread where Gerald mentions that it would work if the monitor and the LCD are the same resolution. Gerald later states that "the HDMI function needs to be disabled to allow something other than 1024x768 to be sent to those pins," which seems to contradict his earlier statement that the HDMI framer and LCD can be run in parallel. Also, the link given by Gerald is to the FAQ which specifically says "The HDMI framer cannot be disabled via SW" and mentions the pins are configured using the Capemanager and mentions a workaround. The workaround seems to require use of the uENV.txt file which can only be edited via USB. Astonishingly, the OP figures out how to disable the HDMI and does something that enables LCD4 firmware. None of which I've been doing when I switch between the LCD7 and the HDMI monitor. Perhaps it's not actually necessary? The OP asks about signal timing and Gerald starts getting snotty for some reason. Other people ask questions I need to know the answer to and Gerald just replies with "search the forum." That is particularly snide considering that the forum tree has "Newbie" in the path. https://groups.google.com/forum/#!topic/beagleboard/-4Q3UnqxY3k

This is the work-around of disabling the onboard HDMI by editing the uEnv.txt file. It also shows checking a configuration file for the capemanager: http://elinux.org/Beagleboard:Weather_Cape_Work-Around

Interestingly, the forum thread from the HDMI question above is a branch of a forum thread tree that starts at beaglebone/hdmi. Promisingly, one of the first threads in the list is LCD as well as HDMI. Here's the topic list, there is so much potential information here: https://groups.google.com/forum/#!categories/beagleboard/hdmi

So, I followed the instructions from the wiki for running xrandr --verbose to get the information on whatever monitor which the BBB is booting to. Strangely the HDMI monitor on my desk seems to support only one resolution: current, min and max are all 1280x720. When using the LCD7, current, min, and max are all 800x480. This may imply that the LCD7 does not support 640x480 as supposedly required.

Looking at the problem a different way, maybe I could find a way to write a script to selectively enable or disable the LCD7 cape so that if it's disabled the HDMI framer finds my monitor. Is there a way to disable a cape from the command line? Hard to say. Here are some links:

Here are some instructions for modifying uEnv.txt. It seems like it's being done from the command line. But maybe it's through the USB. Must re-re-reread: https://groups.google.com/forum/#!topic/beagleboard/aU__9RGq3xU

Here is another example of setting up uEnv.txt. It's for a completely unrelated example, but still helpful. http://tinkernow.com/2015/01/beaglebone-black-rs232-uart-setup/

Here's a link I've gone through before while trying to get Device Tree working for installing the RTC chip; it shows using overlays to install and deinstall a cape, but in the end it finishes up with editing the uEnv.txt file for permanent installation of a cape. This link also has one a very friendly example of chekcing the capemanager slots file to see what is installed. : https://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/exporting-and-unexporting-an-overlay

When I check the slots file with the LCD7 installed, it does not list the virtual HDMI cape for some reason! It shows the LCD7 cape in slot 0 and the eMMC in slot 4 but nothing else. Is the driver for the LCD7 completely deinstalling the HDMI cape at bootup?

Here is perhaps what I was looking for. This is a fairly long forum thread. It starts off with somebody trying to edit uEnv.txt in /boot and not getting the desired result, somebody confirms that it's "the wrong uEnv.txt". They suggest "mounting the FAT partition of the EMMC". Somebody else looks at the environment variables and is interested in what it says about the locations of the uEnv.txt file and the fdt file (which seems to be the device tree setup), and proposes changing the setup to use a different uEnv.txt. The OP finds that the FAT partition can be found through a roundabout method of using fdisk to see all partitions and then picking the one that looks most likely to be the right one and mounting it. Note that the partition name used, mmcblk0p1, is mentioned in several other sources which I haven't had time to list yet. The guy that wants to try changing what file is used at boot time tries a though experiment but in the end he comes up with no answer. https://groups.google.com/forum/#!msg/beagleboard/77IuIt1OCss/O2-kKXHFTmQJ

This is the link that explained why the LCD7 and the HDMI couldn't seem to play together. It turns out that it's because the LCD7 is a touch screen also, and it's apparently set up to use both chip selects on the SPI1 bus which apparently locks out the HDMI interface. I wasn't quite able to figure out from this how the drivers figure out how to not enable the HDMI if the LCD7 is connected, but it confirmed that the two are exclusive and I could never as a result have gotten an HDMI signal at any resolution if the LCD7 is connected. Interestingly, this is a github page which is usually used for code repositories, but this page is set up like a wiki page and is the most exquisitely referenced of any I have ever seen from the BeagleBone community. I should eventually read every link in this page:
https://github.com/notro/fbtft/wiki/BeagleBone-Black

While trying to find the previous link again, I did this google search which unearthed some incredibly juicy looking links about interfacing LCD screens in general that I'd love to get back to again:
https://www.google.com/?gws_rd=ssl#q=beaglebone+black+hdmi+lcd+spi+bus

So, now my idea is to see if there is some way to disable the LCD7 cape without disconnecting it, in such a way that the HDMI interface is allowed to boot up. My first idea was to find whatever Device Tree file is used for the LCD7 cape and either modify it or change its name so it can't be accessed, or maybe modify the main Device Tree files to disable the loading of the LCD7 cape. In the end it didn't work at all; there are no dtbo files for the LCD7 in the appropriate directory and I couldn't find the .dti file for the system (I guess in retrospect it wouldn't have been useful since my system Device Tree was already compiled, duh). The LCD7 seems to be one of the capes that is essentially "built in" to the kernel. However, as a result of all this searching, I read through a lot more very good links about Device Tree and also the Capemanager.

Update 3/10/2016: So, after all that searching, I learned enough to discover that the problem was not as difficult to solve as I had feared. After failing to find a way to disable LCD booting through messing around with .dtb files, I began investigating my options for modifying the uEnv.txt file. Many sources have reported that it is only accessible from the FAT partition over USB, but I had links which showed how to mount that partition into my Linux session so I tried that. I was able to find and mount the partition, but to my surprise, there was no uEnv.txt file there! It had nfs_uEnv.txt and all the html files that come up when you connect the bone as a thumb drive, but no uEnv.txt. A look at nfs_uEnv.txt clearly showed that it didn't have the functions that uEnv.txt does. /boot did have a uEnv.txt file, often described as not the one used for booting, but I tried adding a line to it to disable the LCD cape and boom the BBB rebooted with the LCD disabled and it found the HDMI screen that was connected. So, this file is fairly easy to make a shell script for that switches it between disabling or not disabling the LCD, without requiring any additional partition mounting! I think that the reason why this turned out to be easy after all is that I am running the BBB from SD card; probably when running from eMMC it must use the uEnv.txt file from the FAT partition. Either that or maybe it has a hierarchy of going to the /boot directory if it doesn't find uEnv.txt in the FAT partition, and I got lucky because my particular distro (3.8.13.bone-70) didn't come with that file in that partition.

Tkinter make a widget invisible or visible

The "disable" function greys out a check button and even a label, but is it possible to temporarily make those disappear off a screeen and reappear? So far what I've found seems to indicate that there are a couple of options. There seem to be some utilities for undoing packing in such a way that it's possible to easily redo it. It might also be possible to play with front and back layering to cover and uncover items on a GUI. Here are some links:

This is a nice discussion of these two methods: http://stackoverflow.com/questions/3819354/in-tkinter-is-there-any-way-to-make-a-widget-not-visible

A terse version of the same answer (it points to the first link as already answered): http://stackoverflow.com/questions/10267465/showing-and-hiding-widgets

Only slightly related, here's a cautionary tale about a guy who made a mess of his frame managers and how it was fixed: http://stackoverflow.com/questions/30061100/tkinter-self-grid-making-widgets-invisible

Beaglebone Black Boot Only From SD Card

After my unpleasant experience with the BBB crashing and corrupting it's own OS in eMMC, I decided that to use BBB in my application I have to ensure its reliability by forcing it to boot from SD card like the original Beaglebone. After a bit of a scare where it seemed as though this always required the boot button to be pressed on the board itself (it does not always require this, only when there is a viable OS in eMMC), I uncovered various sources which explained which configuration file on the BBB to lobotomize to make it boot from SD card every time without having to push any buttons on the board.

This link is typical of most instructions for booting from SD in that it mentions holding the boot button on the card without explaining any further. Also it includes the usual instructions for using the SD card to load the OS into the eMMC. Despite not being what I was looking for, this was notable for being one of the clearest guides to getting started with upgrading the BBB to Debian outside of BeagleBone's own web pages: http://thethingsystem.com/dev/Bootstrapping-the-BeagleBone-Black-with-Debian.html

The BeagleBone:Debian wiki is a maze of poor documentation, I'm afraid. Here is the map through the maze that I've developed as a result of feeling my way through it multiple times:

Here is the top-level wiki page for how to install Debian. It makes mention of an image "that can run from a microSD card" but that link just goes to another wiki page. It's actually easier just to get the SD image from the BeagleBoard.org page; through trial and error I've verified that the same image works fine on both the original BeagleBone and BBB. Further down the page, it mentions having to hold the boot button and provides a link to a FAQ that supposedly answers how to boot from SD every time. That FAQ is just a link to yet another page. http://elinux.org/Beagleboard:Debian_On_BeagleBone_Black

Here's where the link to "an image that can run from a microSD card" goes. It's a confused tangle of a whole pile of different images, from ones for eMMC, stripped down ones, ones for other Beagle products, and in there is a prebuilt image for SD card. Again, easier just to go to BeagleBoard.org. http://elinux.org/BeagleBoardDebian#BeagleBone.2FBeagleBone_Black

Here is a different page on the wiki for an image for SD card. In a block quote, it has the first clue about what modifications on the eMMC to cause it to go to the SD card by default. The hint has us deleting the MLO file (which apparently can only be accessed by mounting the BBB as a thumb drive). However, other instructors mention just renaming the file which is clearly a wiser method. http://elinux.org/Beagleboard:Updating_The_Software#Image_For_Booting_From_microSD

Here is one of those corroborating links for the method of deleting/renaming the MLO file: http://perf.tamu.edu/perftech/beaglebone-black-boot-from-the-minisd-card/

In my case, since the eMMC had been fully corrupted, I didn't have to touch the MLO file. I was able to move the SD card from my BeagleBone to the BBB and everything worked exactly the same, except that now I can hook up an HDMI monitor (more on that later). In fact, when I connected the BBB to my PC via USB, nothing mounted, so I never got a chance to try out this hint. I might go through the steps for flashing the OS to the eMMC just to see if I can restore my BBB to factory settings so I can rehearse this hint!

Using Audacity to transpose pitch

It turns out that in addition to having all the high and low pass filtering I could ever need built in, Audacity will let me frequency shift the sound up and down! Neither the effects menu or the help files refer to this as "transposing," unhelpfully; the option is under "Change Pitch" near the top of the effects menu.

https://garagebandmeetupsingapore.wordpress.com/2010/04/25/using-audacity-to-transpose-tracks-change-pitch-without-changing-tempo/

Op Amp Stability

It turns out that the output voltage of one of the op amps that we are using for our fixed voltage source will ring when the load is placed across it using the analog mux. The other op amp truly produces a fixed voltage using a unity gain follower and does not respond to the addition of a load, but the one that has the problem is the one that's supposed to adjust its output to produce the fixed voltage on the other side of a current sense resistor. Searching for ways of improving stability, both I and my coworker initially focused on the usual method of adding damping to the feedback loop with first a resistor and then an RC network. Here are some links that discuss this method. Most of them focus on doing simple frequency analysis that I haven't been able to do for decades and should really refamiliarize myself with.

http://cds.linear.com/docs/en/application-note/an148fa.pdf

http://www.st.com/web/en/resource/technical/document/application_note/CD00176008.pdf

Eventually, I found a couple of forum threads where a guy had a circuit sort of similar to ours, where he was trying to turn on a MOSFET with an op amp and his circuit's step response showed ringing identical to ours. He felt his way to a different looking solution which turned out to be the one that worked great for me, which was putting a capacitor between the output of the op amp and the negative side of the feedback loop. Actually, this seems topologically very similar to having the cap in parallel with the feedback resistor, it merely also includes the sense resistor (or in this person's case the MOSFET Gate-Drain resistance) which is to say the entire feedback loop. In this person's case, he was more interested in understanding why his SPICE model hadn't caught the problem. Anyhow, this feedback topology is actually covered in the above tutorials as the "in the loop" compensation method, and the presence of inline resistance before the feedback is also discussed as a prime cause of instability, so it turns out that all of the sources that I found are actually in agreement.

http://electronics.stackexchange.com/questions/175652/how-to-test-op-amp-stability/175656

http://electronics.stackexchange.com/questions/176669/why-doesnt-ltspice-predict-this-op-amp-oscillation/176696

Import MP3 to MIDI Software

Searching for software which can convert audio to sheet music or MP3. It's basically a lot to ask and doesn't work very well. Also at the moment there aren't a lot of software packages making any promises of being able to work.

Neuratron is a conversion software, but it promises to work only on simple, clear audio with no drums. It's also fantastically expensive: http://www.neuratron.com/order.asp?country=US

The brashest promises I've found are for Intelliscore, which says something like "just play your favorite pop song into the program and watch it unravel": http://www.intelliscore.net/demo.html

People that bought it on Amazon were rather displeased with it: http://www.amazon.com/IntelliScore-Ensemble-Converter-transcription-software/dp/B00A69PA64

Fortunately, Intelliscore offers a free demo version which it has been very instructive to try out: http://www.intelliscore.net/demo.html

The result from just trying the demo was quite a mess, exactly as reported on Amazon. However, any pop music is going to be sonically complex so it's not hard to understand how this might result. Probably the program would do better if I could apply filters to the MP3 to limit the frequency range to either the bass or treble treble ranges. I started searching for programs that could do digital filters since I didn't want to add extra hiss by going through an analog filter. I found hardly any programs that would do this, and I think there are a couple of reasons. There's probably not a sufficient market for stand-alone filter software, and it turns out that good old Audacity has tons of plugins that do filtering.

Here's a list of all the Nyquist plugins including the filters. It turns out that I didn't need to download anything, my copy of Audacity came with everything I needed pre-installed. The list is very interesting however and contains very good descriptions of each filter. http://wiki.audacityteam.org/wiki/Download_Nyquist_Plug-ins

Here's a forum where somebody discusses how to use the filters in Audacity. http://audacity.238276.n2.nabble.com/High-pass-and-Low-Pass-can-t-wrap-my-head-around-em-td241453.html

This is an interesting discussion on the same forum of how to use filters to clean up voice recordings: https://sourceforge.net/p/audacity/mailman/message/26961565/

Eagle Schematic import DXF

As with most things in Eagle, it does not import DXF files natively, but users have written some ULP scripts to do it. The way that these scripts tend to work is that they read the DXF and convert it into Eagle-native draw commands to redraw the contents of the DXF. For some reason, all DXF import scripts that I've found so far just skip importing text from the DXF; all you get is the lines and shapes. In my case, importing a drawing border file, that is enough to get started with.

Cadsoft has a least made it easy to find ULPs by providing hosting and indexing for scripts submitted by their users. If you just go to the following link and type 'DXFimport' into the search tool, you get a variety of versions of this script, starting from an original script and going up to version 1.6 with improvements by several different users resubmitted under the same name and new version levels: http://www.cadsoftusa.com/downloads/ulps

Interestingly, the hint about where to find this came from this post on Cadsoft's own Facebook page concerning version 1.5 of the script: https://www.facebook.com/cadsoftcomputer/posts/556869044353063

Also interestingly, version 1.6 of the script can also be downloaded from github here: https://github.com/erikwilson/import-dxf

This forum post mentions a different script which I haven't tried which might be either better or no longer available: https://www.element14.com/community/thread/16729/l/importing-a-dxf-file-into-eagle-610-steps?displayFullThread=true

Here is another thread where that script is discussed, with links to an article with more detail that I haven't yet tried to follow: https://www.element14.com/community/thread/21171/l/import-dxf-file-in-eagle-pro-620?displayFullThread=true

Can Eagle export a netlist to PADS

A page to accumulate answers that I find to this question. As with most Eagle questions, the answer seems to fall within the realm of "no, but users have written some scripts or something to do it but there are no guarantees."

For now all I have to report is the following interesting link:

A blog post from somebody who I guess wrote a netlist file converter. http://www.neufeld.newton.ks.us/electronics/?p=120

Eagle CAD hints and tips

The learning curve for Eagle is proving to be familiarly painful. Part of this is because much like AutoCAD, it seems to be so loaded with options that it's hard to access them all. Here's a list of important non-intuitive tricks that make it possible to use the software.

1. When creating parts (in my case, borders), you have to draw the part as a "Symbol", then go to Device (where it might or might not be necessary that the new part name match the name of the symbol just defined) and click the "Add" button and add the symbol that you just drew! If you don't do this, when you try to add the part to a schematic, the part is found in the library but it's blank. It's possible to update the symbol later and use the "Update library" function in the schematic tool to pull the changes into the schematic without having to update the "Device" in between.

2. When running the DXF import ULP, you have to be editing a Symbol when you run the ULP and the script that the ULP produces. The ULP simply produces a series of draw commands. It is a good idea to manually fix which layer the drawing is done in (the most recent version of the ULP allows this layer to be chosen ahead of time via dialog).

3. To copy things from one symbol to another, you have to select them as a group, then press the "copy" button while the group is selected. Then you have to close the symbol (can't have more than one up at a time apparently), open the target symbol, then press the "Paste" button to get the copied items attached to your mouse pointer to be set down. A link with the example that helped make this clear:

http://www.bot-thoughts.com/2012/09/eagle-cad-copying-between-schematics.html

4. To manually select items to add to a group rather than using a select border, you need to press control while clicking each item!!! If you accidentally do something that loses the group selection, you can easily get the selection back by pressing the group button again.

5. To do things to a group once the group is selected, you press the button that corresponds to the action (like copy, move, delete, or any of the options under "chanage"), then ctrl-right-click on an item in the group to perform the action on the entire group!!!!!! It is possible to change the size of a bunch of text items in a group with this method if they are all text items.

Here's a link where right-click is explained as important: https://forum.sparkfun.com/viewtopic.php?t=10681

6. To copy a group, such as components and wiring, or a block of text items, select it as a group, then you can right click on the group and get a context menu. None of the context menu items apply to the group except that at the bottom there will be a "Copy: Group" option. You can select that, then close the drawing that you are copying from and open the drawing that you are copying to. This seems to be the sole exception to the pick-an-action-then-ctrl-right-click paradigm described in the previous hint.

Here's a forum thread in which many contributors describe this process: https://forum.sparkfun.com/viewtopic.php?t=2449

7. To create properties for the title block of the border, you add text with the special character '>' in front. Then on the schematic you can create an attribute of the same name for the part to have the value substituted for the word in the part. N.B.: the attribute needs to have display set to 'none' or the value text will show up in both places, in the area of the schematic where the text being substituted is and also as a floating attribute value initially placed next to the handle for the title block. Tom had a lot more familiarity with how it's possible to layer this feature, but for now here is a somewhat funny link in which a bunch of people propose workarounds to avoid using the substitution feature because they don't understand it, and then somebody comments at the bottom thread explaining how it is supposed to work but doesn't get any likes!

http://electronics.stackexchange.com/questions/93773/editing-title-block-frame-in-eagle