abecedarian

A few of us now have the MSP-FET - mainly thanks to TI's ESI project. The target boards are great if you want to prototype something quickly and need to use a device that's only in a SMT package. However they're quite enpensive for hobbyist use. I thought it worth mentioning that I found a US eBay seller hrojas with some target boards for $20 each. He even did me a deal on international shipping as I bought a few. He's got the following: TS430PW28A, TS430RGC64USB, TS430PZ100B, TS430PS24, TS430L092, TS430RGC64C
 
I also noticed that the target boards listed a while ago with TI deals on them are still at that low price - or in some cases even lower. They're shown as full price on the TI site but if you click "buy from TI" the price in your shopping cart is lower. I think I checked them all and these are the ones that come up cheaper than listed. (Some by a lot, some not so much.) These are perhaps the ones that are a little less in demand and aren't selling so well, but they might be useful.
 
TS430L092 - $20
TS430PEU128 - $20
TS430PW24 - $30
TS430DL48 - $40
TS430PN80A - $55
TS430PW28A - $55
TS430PZ100 - $55
TS430RGZ48B - $75
TS430RSB40 - $75

That userguide is not my friend.

Welcome.
 
Not sure about a solenoid / valve but maybe you could find a small 1/4 turn ball-valve and control it with a servo?

@@asdfasdfasdfasdfasdf
If all you did was plug it in, that's to be expected.
 
Download drivers from http://energia.nu/Guide_Windows.html or install CCS from TI's website (registration required).

Sorry for the mega post but as you may have already noticed, lately I

Now we need commercial users to standardize on this so all our home gadgets are hackable!
 
Sent from my Galaxy Note II with Tapatalk 4

Interesting: The MSP430FR4133 reference designs for a thermostat and a water meter come with BoosterPack headers.


 
However the pin-out seems to be only partial. At least it's sufficient to use SPI/I2C.

 
More here: http://e2e.ti.com/blogs_/b/msp430blog/archive/2014/10/16/new-reference-designs-available-based-on-the-new-msp430fr4133-mcu.aspx

@@bluehash - I don't mind the diversion.
 
Well anyhow.
 
Still waiting for the flow meter to arrive. I've been looking online at it and its brethren and realized I have a few AS5140 magnetic rotary position sensors here. They have an incremental mode that provides quadrature output signals so this may be an option to get more accurate flow readings over the basic hall effect sensor. Can't wait to see if I can get one of those working.

Note that channels 12-14 are not legal for full-power use in North America, so depending on your location the fault may be in the configuration of your AP. (I haven't unboxed my CC3200, but I'd be pretty surprised if it couldn't handle at least channels 12 and 13, but not surprised if its default configuration excludes them.)

FYI-
 
https://github.com/spirilis/SLFS
Zip of current code: SLFS.zip
Unzip that in ~/Documents/Energia/libraries or wherever.
 
Be sure you have an updated copy of the WiFi library, as it needs WiFi.init() to be a public method.
My latest copy is here: simplelink_wifi_library_latest_10142014.zip - unzip that from within your Energia install's toplevel directory (e.g. from within C:\energia-0101E0013).
(that actually has one change ahead of Energia's current github master; it moves the various WiFi buffers to .text section on FRAM chips so they will fit on the Wolverine FR5969 LaunchPad w/ CC3100)
 
 
The SLFS library declares an instance right away called "SerFlash", so SerFlash.open(), SerFlash.close(), SerFlash.write(), SerFlash.print(), SerFlash.println(), etc...
You can delete files using SerFlash.del()
You cannot list the directory contents or know what files are on the flash.  I did not find any API calls in the SimpleLink API that support such a feature.  I'm assuming it's been left out for security reasons or similar.
 
The open() system call is given options based on the sl_FsOpen() SimpleLink API call, so... looking at documentation here- http://software-dl.ti.com/ecs/cc31xx/APIs/public/cc31xx_simplelink/latest/html/index.html ... look at "File System" and then "sl_FsOpen":
open file for read or write from/to storage device Parameters [in] pFileName File Name buffer pointer [in] AccessModeAndMaxSize Options: As described below [in] pToken Reserved for future use. Use NULL for this field [out] pFileHandle Pointing on the file and used for read and write commands to the file AccessModeAndMaxSize possible input FS_MODE_OPEN_READ - Read a file FS_MODE_OPEN_WRITE - Open for write for an existing file FS_MODE_OPEN_CREATE(maxSizeInBytes,accessModeFlags) - Open for creating a new file. Max file size is defined in bytes. For optimal FS size, use max size in 4K-512 bytes steps (e.g. 3584,7680,117760) Several access modes bits can be combined together from SlFileOpenFlags_e enum The syntax for SerFlash.open() therefore is something like this:
 
SerFlash.open("myfile.txt", FS_MODE_OPEN_READ);  // Open file for reading
SerFlash.open("myfile.txt", FS_MODE_OPEN_CREATE(1024, _FS_FILE_OPEN_FLAG_COMMIT));  // Create new file, allocated 1024 bytes to contain it
SerFlash.open("myfile.txt", FS_MODE_OPEN_WRITE);  // Open file for re-writing
 
From what I've been able to gather, you can't open an existing file and write pieces of it piecemeal; opening the file and writing forces the serial flash to erase the entire block, so what you write replaces the prior contents entirely.  So for updating configuration info, you would need to read it into memory, make your changes and then re-write the entire file.  Also, there's a maximum # of files you can store ... something like 128 I believe, and that includes a number of system files in that count which are already there.  It's not meant to be a huge filesystem.  But it should do the trick for a lot of uses.
 

Probably something about the manufacturing process. 
Same slat151 also states: "...our newest generation of devices can survive the same soldering and reflow conditions as any Flash part. Data retention on older FRAM memory, however, cannot be guaranteed when exceeding the specified maximum storage temperature (150?C)."
...and...
"If hand soldering is required for application prototyping of MSP430FR57xx devices, peak temperature must not exceed 250

FR57xx is listed here, on the products page, and being shown as active.
 
Perhaps TI is 'deprecating' them due to the following blurb in http://www.ti.com/lit/ml/slat151/slat151.pdf: {emphasis added} "The MSP430FR58xx and MSP430FR59xx family of devices, and all FRAM-based MSP430 products released in 2014 or later will support application programming of devices prior to reflow. For the FR57xx family only, application programming is recommended post reflow."?

FR57xx is listed here, on the products page, and being shown as active.
 
Perhaps TI is 'deprecating' them due to the following blurb in http://www.ti.com/lit/ml/slat151/slat151.pdf: {emphasis added} "The MSP430FR58xx and MSP430FR59xx family of devices, and all FRAM-based MSP430 products released in 2014 or later will support application programming of devices prior to reflow. For the FR57xx family only, application programming is recommended post reflow."?

Getting my wife to be impressed with my skills required barbecuing a pot roast.
 
Beyond that, any mention of chips makes her ask "where's the salsa?"

Device family guide for FR4xx & FR2xx:
http://www.ti.com/lit/pdf/slau445 Page 104.
 

Interesting, definitely like the educational opportunities for the kids, better to learn this stuff then spend all of their time playing mine craft!
 
Here's the details on droplet, the schematic ain't pretty but I didn't feel like spending time bringing it to a professional caliber.  I built up 6 of the original revision, found a few bugs taht were all fixed in this revision, it should be good to go.
 
https://upverter.com/imp-guru/0609e08f25aa7f3d/Humidity--Temp-Guru/
 
I just finished up the hub board, have not tested it yet
 
https://upverter.com/imp-guru/84ba884b5851ecba/Imp-Guru-Sensor-Hub/
 
The hub has the cc1190 frontend chip as well so I'm hoping for long range, we'll see what I can get.
 
for either design you can click on "Download associated files" and grab a zip of the gerbers which are perfectly formatted to submit to oshpark

if(value >= (oldValue-sensitivity) || value <= (oldValue+sensitivity)) This will always return true.
This method will do what you want if you switch things around a little bit. You want to check to see if the new number is less than X - sensitivity or more than X + sensitivity, and if it is then you run your code.
If it isn't then you return false as the number is still within the sensitivity range.
 
[code]if(value <= (oldValue-sensitivity) || value >= (oldValue+sensitivity)){    doStuff();    return true; } else{   return false; } Just as an example. Please do note that the above has not actually been compiled/run.
 
 
Or do what abec. suggested, the end result is the same.
 
I'm not sure you need to check for 0 and 1023 specifically. If the last read was 1023 and the next read is also 1023 that will fall within the sensitivity range and be ignored.
Maybe I'm missing something there.
 
 
 
If you have time, do a few more samples with a bit of time between them.
If I can I like to sample decently often over a ~17ms time period to get rid of the 60Hz background EMI.
A running average can be a nice tool for this sort of thing too. Take value and add the last-read value then divide by 2. Very low memory usage, with decent long term averaging.
A small cap between the ADC input pin and GND or VCC can go a long way too, especially if it's a high resistance slow changing (relatively) input.

Let's not get into a discussion about religion. I'll get frustrated. You'll get offended. Everyone else will be bored. We believe different things. Let's just leave it at that.

Wow guys... I've been working with this code for so long and never even realized it was the OR operator in the if statement... I feel so embarrassed. I've been programming for a few years now, even on MSP430.
 
Hahaha, I guess it really takes a few fresh eyes to pick out the little mistakes like that. I will recompile it with the && operator when I have the change and see how much it improves.
 
I may try the running average idea. I could also try upping the sample count and balance the latency with the stableness of the readings.
 
Also, the purpose of the check for absolute mins/maxs (0/1023) is so that if I have a previous sent value, for example 1018, it's in the sensitivity range so 1023 will never be sent. I will never register totally 0 or totally 1023, which is critical for my project. Therefore, I have to explicitly check to see if it's a max/min value, and then send it if it hasn't been sent before.
 
I'll check back with you guys again if I have anymore problems. Thanks again for catching my dumb mistakes!

http://www.mouser.com/MultiSimBlue/
 
Circuit simulation, PCB layout, et cetera.

@@Fred - it appears it does support IrDA encode / decode with the eUSCI_A0 module. See slau445.pdf, page 441.

I don't think you want an "OR" in the comparison. No matter what "value" is, it will return true.
I.e. if 'value' is 512, 'oldValue' is 508, and the sensitivity is 10, 508-10 is 498, so the >= is true; and 508+10 is 518, so the <= is true as well. But, if 'value' is 19, 508+10 is 518, so the <= comparison is true and therefore the IF statement is true when using "||" / OR. Likewise, if 'value' is 988, 508-10 is 498, so the >= comparison is similarly true.
 
So maybe:

if((value >= (oldValue-sensitivity)) && (value <= (oldValue+sensitivity)))? 
Also, you should constrain / bound "oldValue" with the sensitivity calcs so that it doesn't over / under flow the 0-1023 limits, no?

I don't think you want an "OR" in the comparison. No matter what "value" is, it will return true.
I.e. if 'value' is 512, 'oldValue' is 508, and the sensitivity is 10, 508-10 is 498, so the >= is true; and 508+10 is 518, so the <= is true as well. But, if 'value' is 19, 508+10 is 518, so the <= comparison is true and therefore the IF statement is true when using "||" / OR. Likewise, if 'value' is 988, 508-10 is 498, so the >= comparison is similarly true.
 
So maybe:

if((value >= (oldValue-sensitivity)) && (value <= (oldValue+sensitivity)))? 
Also, you should constrain / bound "oldValue" with the sensitivity calcs so that it doesn't over / under flow the 0-1023 limits, no?

Even less time! Amazing!
 
Did figure out exactly what I want to do with the ESI bits though. I'm thinking that their ability to start/stop a timer to measure a pulse width is going to be used to collect ON time of a fuel injector.
For the early going I'll just measure fuel in seconds of flow per distance, or seconds of flow per trip. It won't be something that can be converted to MPG, but it'll be easy to see the difference driving style/etc. makes.
 
Having the ESI do the timer running means not having to use CPU cycles to do it but still getting a good solid time on it, which I like.
 
 
Spent some time trying to get the UART transmitting for debuging. Didn't manage to. I need to pry the setup out of the Energia FR5969 setup bits and try that.

Weird it looks like their site is down.
 
Here's a decent video 
 
there is also their crowd funding site: http://www.dragoninnovation.com/projects/16-dash-the-diy-robot
 
Jus the control board is also for sale on tindie: https://www.tindie.com/products/DashRobotics/dashboard/