timb

Hey everyone, I

Hey everyone, I

Hey everyone, I

Hey everyone, I

Oh, and here is a basic tree of how simple the structure would be in terms of libraries if I went the custom route. This may be the way I go ultimately for speed. I might initially start off with a simpler web interface that allows you to define instruments and simply write scripts for them. Once that

Thanks!
 
Right now, I

Looks nice and well packed @@timb
I've never worked with GPIBs before. Will you be coding up your own frontend? Also could you give me examples of instruments you would add support for?

So, as I

So, as I

Ahh, I guess they’re using a custom protocol that will only work with their custom iOS/Android apps. They say it’s for use with your BBB outdoors, but why wouldn’t I just grab a $10 WiFi adapter and set it up as an ad-hoc network or base station? Then I could SSH into it from any device...
 
Also, there’s already a host of $5~ Bluetooth Serial Modules that will do the same thing, but don’t require a custom app. (I use this method literally all the time; I’ve got about 5 of these adapters and use them to program/debug everything from my MSP430s to Spark Cores to BeagleBones.

I’m working on an open test instrument platform for the BBB; in doing so I’m splitting it up into various sub-projects. I thought the community would be interested in the 5” LCD I’ve got going for independent use, so I plan on making a standalone cape for it, for those interested.
 
The CircuitCo and 4DSystems 7” LCDs currently on the market both run at 800x480 and use standard 24-Bit Pixel Clock interfaces over. The CircuitCo LCD has a 60-pin ZIF interface, while the 4DSystems version uses the more common 40-pin ZIF connector. The difference essentially comes down to power: LCDs with 40-pin interfaces will run straight off of 5V, while the 60-pin panels require a bunch of voltage levels to be externally generated (+10, +15, -7 in the case of the CircuitCo panel).
 
So, this got me thinking… There’s a plethora of 5” LCDs with an 800x480 resolution and 40-pin interfaces on the market. I figured as long as it used the same electrical interface and resolution, it should work straight off with the BB-BONE-LCD7-01 overlay (this is how the 4DSystems 7” panel works). As it turns out, I was right! Currently I’ve got the screen up and running with a standard 4-pin resistive touchscreen, however I’ve got a nice capacitive overlay on the way from China, which will be used in the final version of the board.
 
Here’s a few pictures of the test setup up and running. The last picture is a closeup of the display, but it really doesn’t do the quality justice. Hopefully I’ll have the Cape done this week. If there’s any interest I’ll order a dozen or so boards and sell them to members at cost for testing. 
 
 

 

 

 

 
 
 
 
 

I’m working on an open test instrument platform for the BBB; in doing so I’m splitting it up into various sub-projects. I thought the community would be interested in the 5” LCD I’ve got going for independent use, so I plan on making a standalone cape for it, for those interested.
 
The CircuitCo and 4DSystems 7” LCDs currently on the market both run at 800x480 and use standard 24-Bit Pixel Clock interfaces over. The CircuitCo LCD has a 60-pin ZIF interface, while the 4DSystems version uses the more common 40-pin ZIF connector. The difference essentially comes down to power: LCDs with 40-pin interfaces will run straight off of 5V, while the 60-pin panels require a bunch of voltage levels to be externally generated (+10, +15, -7 in the case of the CircuitCo panel).
 
So, this got me thinking… There’s a plethora of 5” LCDs with an 800x480 resolution and 40-pin interfaces on the market. I figured as long as it used the same electrical interface and resolution, it should work straight off with the BB-BONE-LCD7-01 overlay (this is how the 4DSystems 7” panel works). As it turns out, I was right! Currently I’ve got the screen up and running with a standard 4-pin resistive touchscreen, however I’ve got a nice capacitive overlay on the way from China, which will be used in the final version of the board.
 
Here’s a few pictures of the test setup up and running. The last picture is a closeup of the display, but it really doesn’t do the quality justice. Hopefully I’ll have the Cape done this week. If there’s any interest I’ll order a dozen or so boards and sell them to members at cost for testing. 
 
 

 

 

 

 
 
 
 
 

Below is a two part series on using the beaglebone PRUs, by Fabien Mentec, on Embedded Related.
 
http://www.embeddedrelated.com/showarticle/586.php
 
The second article discusses using  C to program the am335x PRU:
http://www.embeddedrelated.com/showarticle/603.php
 
Enjoy!

Cool.  The stock Chronos 433 antenna is absolute rubbish, though, so it is a low bar.
 
In any case, I can mail you a hand-built ~5cm reference monopole, if you want to compare RSSI readings (send me a PM).  I have tons of these, which I manufacture in the lab.  Normally I don't offer this sort of thing, but you are actually working on something that is of interest to me.  The same offer goes towards anyone doing 433 MHz Chronos work, or for that matter CC430, CC11xx, and CC1200 work.
 
It's also important to mention that a single-ended antenna (monopole) needs a decent-sized ground plane to work properly.  The Chronos doesn't offer this, but if it is plugged-in to a USB cable or some other path to mains-power, this will serve as an excellent ground (even plugged into a battery powered laptop, smartphone, etc, this is plenty of grounding).  As soon as you remove this ground, the antenna performance will get much worse.  Ideally your ground plane on a monopole configuration has radius of quarter-wave, but if you don't need wide bandwidth you can hack a decent antenna system just by having the perimeter of the ground plane >= half-wave (in this case, you are actually building a dipole).

Hey all!
 
This is Adrian from TI. We absolutely love this effort! To show our support, we'd like to enable you folks with some CC430 Chronos dev kits to help you out! Please send me a PM with your preferred shipping address & we'll send you a Chronos kit ASAP!
 
Thanks - we love the Energia project and I may or may not be wearing a Chronos watch right now
 
Cheers,
Adrian

Good to hear about the current consumption!
 
Tonight I got the buttons soldered down, the buzzer installed and I hand made a helical antenna tuned to 433MHz. Just have to get the power supply on this afternoon and she'll be ready to roll!
 

 

rfBSL Update: Okay, so I've written a Python app (based partial on ChronosTool.py and the iHEX to TI-TXT script [memory.py) from OpenChronos) that takes a .hex file as an input and uploads it over rfBSL. I then used pyInstaller to "compile" the script into a fully self-contained executable for Windows, Linux and OS X. This way the user doesn't need Python (or any additional libraries) installed and we don't have to include the bulky jython (Java Python) interpreter.
 
Each executable weighs in at about 5MB and could be included in the Windows, Linux and Mac specific tools folder of Energia.
 
Once I do some more testing I'll post a copy of the files, but I welcome any feedback on this method.

The wireless dongle included in the eZ430-Chronos kit will work just fine for rfBSL updating. (Both the Black PCB CC1111 and White PCB MSP430F5509 + CC1101 dongles will work.)
 
For non-Chronos CC430 options, you could use the above dongles, or as @@B@tto mentioned, a CC110L hooked to an Arduino or MSP430 and connected to your computer over USB.
 
@@B@tto Yeah, HEX to TI-TXT conversion is easy, there's a ton of tools out there that will do it for you, most of them lightweight. I think the best course of action would be for me to write a simple little CLI app that directly takes a HEX file and then internally converts it to TI-TXT and uploads it via rfBSL. I can then cross-compile the program for Mac, Windows and Linux.

@@timb, I will look around and let you know.
 
I found this one so far. 
 
Maybe it's time to design another board with alternate pinout or jumpers to switch between different LCD versions.

Thanks @@timb. I fixed the store link.

@@bluehash Just an FYI, the schematic/pinout listed on the product page is incorrect. You should be using the one from this post. The jumper pinouts changed significantly, so I'm sure it's very confusing to people who stumble onto the store or this thread. (Every time I go back to use one of the shields I always end up checking the jumper pinout and then get confused why D/C isn't working!)

@@timb It already is: http://store.43oh.com/index.php?route=product/product&product_id=75&search=5110

Yeah, I'm using Release 11. @@Rei Vilo mentioned something to me about an issue with alternate SPI ports on Tiva/Stellaris boards in the latest Energia release? Something about an older set of pin definitions or SPI library being used, I think. I tried replacing the files in hardware/lm4f/libraries/spi with the current versions from Github, but it didn't seem to make a difference.
 
I tried a simple test last night by hooking my Logic 16 up to the SPI0 pins and just writing some test data out. It compiles fine, but I'm not picking anything up. Do you want to give it a test and see if it's working on your end?
 
As an aside, does Energia support the other I2C modules on the Tiva C? Some of the SENSHUB's sensors will need that.

Awesome you got this to work @@timb!
 
Are you using Energia 11? I was sure that SPI.setModule(0) passed the tests with Energia 11 but since you see issues with it I am not sure it really did.

Boom, baby!
 

 
I used jumper straps to re-wire the SENSHUB board's RF_SPI outputs to the SPI2 pins on the Tiva C Launchpad. Ran the "Firmware Upgrade" sketch, which successfully completed in about 5 seconds, then put the "Simple Web Server" sketch on, which oddly wouldn't connect to my unencrypted network (used the WiFi.begin(ssid); line instead of WiFi.begin(ssid, pass);). I didn't think it would handle the main (WPA2) network since the SSID contains spaces and the ampersand, impressively it worked just fine!
 
So, here's the $10,000,000 question: Can I get Energia to use SPI0 instead of SPI2? If so, the BOOSTXL-SENSHUB will 100% work as an RF adapter for the CC3000 on Tiva C boards under Energia. TI sometimes bundles those two items together at a very generous price, so it might be handy if we could implement support for it if possible. This particular BoosterPack, um, packs a ton of sensors that could be handy to read over WiFi. If support for SPI0 is possible, I'd love to write up a variant of the simpleWebServer sketch that serves up a dynamically updating page with all the sensor data, as an example of this board combination.