Exploring IoT… A practical approach, Part 3

The last and final part!

What was supposed to be a quick proof-of-concept project, ended up as a 1-month marathon! This is precisely why I don’t intend to spend to much time in explaining each and every obstacle I encountered along the way. Heck, I might even miss something!?

But the learning experience was invaluable despite the extra time I spent finishing this up.

So here it is… In all it’s glory šŸ™‚

Weight Scale IoT protoboard

This is a crude wiring – just to test out the software part.

And this is the “schematic”:

Weight Scale IoT wiring diagram

This is the “compact” version – without the breadboard:


And this is the result on my chosen IoT platform:

Truck Weighing UbidotsMy initial goal (after realizing that my pin assignment conflicts with that of the CC3100 booster pack) was to use an extra MSP430 micro, to which I would connect the scale directly on its physical UART, and then use 2 additional pins for the SoftwareSerial. I would then use SPI for the communication between the main board (the TM4C or the Tiva C) and the ultra low power MSP430G2553.

I then realized that the SoftwareSerial implementation ‘eats up’ almost 90% of the MSP430 memory (along with everything else I’ve put in), so I decided to abandon the idea and go straight to using two dedicated MSP430s.

Then I abandoned the SPI in favor of I2C. I don’t know… the code seemed more straightforward? šŸ™‚

Again, I neglected to read the documentation and forgot to remove the jumper on P1.6, which is kind of essential if you want to use the physical I2C and not the software emulated one – which you need to indicate in the library source code:

Setting HW I2C on the MSP430

Somewhere along the process, I experienced difficulties receiving more than 8 bytes at once (trough I2C), so I set up my code to split my packets in groups of 8 bytes (1 word).

I then experienced the same thing with the RS232 protocol, only to realize that there’s a limit on the receiving buffer – inside the library!? Making sure I have plenty of memory to spare :), I increased the buffer size – realizing I could have done the same with the I2C buffer:

Setting HW Serial Buffer Size

And everything else in-between I honestly don’t remember anymore. I just wanted to get this over with and neglected taking notes. But I don’t think it was anything significant.

One thing I do remember though, was that I was “struggling” with the Ubidots library.

After some code analysis and some crude debugging (using Serial.println() what else!), I realized that the HTTP request was incorrect (because of incomplete JSON data), essentially resulting in:

{“detail”: “JSON parse error – Expecting value: line 1 column 16 (char 15)”}

What it turned out was, the sprintf doesn’t really work under the Arduino/Energia tool chain with the %f format specifier which boils down to ‘you can’t use sprintf like you would normally do to convert a float to a string‘! Hence the introduction of the dtostrf function. But here’s the catch: it too doesn’t really work under Energia – or at least it didn’t work in my case! In fact, I read similar comments on the Internet – but again, I was so focused on get this finally done, and forgot to bookmark those pages šŸ˜¦

Nevertheless, I introduced a dirty, but nonetheless a valid and a working trick in the library provided by Ubidots (in fact, I branched the mod and requested a merge):

if the %f specifier doesn’t work with sprintf and Arduino/Energia, no one said anything about the %d specifier not working!


/* Saves variable value in str */
// dtostrf(_value, 4, 3, str_val); // String variable value
int _ivalue = (int)_value;
sprintf(str_val, "%d.%d", _ivalue, (int)((_value -_ivalue)*1000)); // Precision of 3 decimal places

After this experience, I think I would just concentrate more on using the tools straight from the supplier and resist the temptation of using any wrappers.

And there you go. All else you can find on my BitBucket repo!