With the recent surge in Omicron cases, shipping may be slower than stated times. We are working to build, ship and respond to everything as quickly as possible. Please see all COVID-19 updates here. Thank you for your continued support.



Member Since: April 17, 2007

Country: United States

  • I've got a really rough design for a layered laser cut case. I'll try to clean it up and post it in the next week or so.

  • Does the touchscreen only work inside of X or is does it use a normal touchscreen driver?

    I'd like to use it in a non-X custom GUI app...

    EDIT: After banging my head against this for a while, I finally got this cape (mostly) working with the SGX video driver using a 3.14 version of the kernel. The kernel image I used was put together by Thing Printer and, while it's limited, if you're trying to do graphics, this image along with a working dts/dtbo file can get you a nice dev platform for embedded, OpenGL ES projects.

    Here's the blog post about the kernel: http://www.thing-printer.com/pvr-sgx-3-14-capemgr-clutter-bbb/

    And here's the repo with the dts file along with some notes on how to get it working with that image: https://github.com/JamesHagerman/4D-7in-LCD-Cape-Fixes-for-3.12

  • Also, if you're interested in seeing the evidence in GNU screen where this limit seems to exist, look at line 1422 of the tty.sh file in the screen src tree:


    Now I need to find a decent OS X terminal app that actually works at 500kbps...

  • Ah ha! I found something important to keep in mind when you're using this board at 500kbps:

    GNU Screen is limited to (or missing configurations higher than) 460800bps. That's 460kbps.

    So, don't try using screen /dev/tty.yourusbserialport 500000 to communicate with this board and expect it to respond.

    If you set the baud rate on the board by saving the baud rate to the onboard memory, and you end up locking yourself out of the board because you don't have a device that can be set to that baud rate, there's a simple fix!

    Short the RST_NVM to the GND pad right next to it (ya might even wanna solder on some headers for this). Once they are shorted, plug the board into the car, and wait until the RX light starts blinking rapidly.

    Once it's been blinking for a few seconds, disconnect it from the car, UN-SHORT the RST_NVM and GND pads, and try connecting back to the board at either 9600 or 38400 baud.

    You should be back in business!

  • I pulled this board out of storage again today and had a pretty awesome "Ah ha!" moment when I realized that someone had probably written a Ruby gem for all this OBD II stuff...

    And sure enough, someone did! After forking the existing code, and cherry picking all the awesome bits into my fork, I'm happy to say that this is, by far, the easiest way of interfacing with these boards that I've found. Here's the fresh fork: https://github.com/JamesHagerman/obd

    My plan is to start building in some OBD II monitor mode logging in the obd gem in order to start reverse engineering the non-standard ISO 15765-4 (CAN 29/500) modes.

    If you're at all interested in hacking your car, I seriously suggest picking one of these boards up before they're all gone. They work WAY better then the Arduino shields, and really open up the doors to getting into CAN bus hacking without having to worry about that cheapo OBD II scanner you got on ebay.

  • This is great! Thank you so much for the work! Your tutorial is really helpful!

  • I'll check it out! Thank you!

  • Thank you so much for the quick responses! It really does mean a lot!

  • Further, this thing defaults to 720p! There is no way (as of yet) to get the board to run at 1080p. I've modified the hell out of the xorg.conf and it fails because the /dev/fb0 is set somewhere in the (difficult to modify) boot configuration to be 1280x720!


    Back to hammering away at the Raspberry Pi I guess... at least until the lima driver (http://limadriver.org/) guys bend over backwards to reverse engineer ARM's stupid, proprietary silicon...

  • This board has the same issue the Raspberry Pi does! The video drivers SUCK!

    The Mali-400 driver seems to just wrap the fbdev at /dev/fb0! This means NO hardware acceleration!

    What the hell!? This is the downfall of ALL of these boards in my opinion! Why can't these companies just give us solid device drivers!?!?

    Everyone runs X! Everyone wants hardware acceleration in the UI! There is no point in having GNOME MPlayer on the desktop because it WILL NOT play video!!

    What a let down!