Exploring IoT… A practical approach, Part 2

This was originally intended to be a 2 part article. But between work and my good intentions to close the topic before my 30 day trial period of Ubidots finishes up, I managed to hit a brick wall!

My plan was simple:

IoT enabled Industrial Weight Scale _ concept idea

My IoT enabled device is connected to my internal LAN through WiFi. It uses TI’s CC3100 booster pack for this. I use 2 of it’s 7 (if I’m not mistaken?) UARTs: one to interface to the weight scale indicator and the other one to interface to the PC. Whatever is coming from the scale indicator is routed directly to the PC. This way, all of the existing functionality isn’t broken and the PC application continues to do what it was intended to do! At the same time, I parse this data, extract the part I’m interested in (e.g. the weight under measurement) and send it to my Ubidots “monitoring” application.

Here’s what happened…

This is my hardware setup:

IoT enabled Industrial Weight Scale _ with labels

… and just to show it’s not only boards stacked on a perf-board:

IoT enabled Industrial Weight Scale _ bottom side

Not my best work, but it will do! 🙂

My first TODO item was to work out the RS232 part. Now, as you cannot just directly interface a microntroller’s UART directly to a RS232 port (mainly because of completely different voltage levels!), you need to use a TTL-to-RS232 level converter. I was lazy and didn’t want to solder too much, so I opted for the RS232 Click from MikroElektronika. And nothing worked (initially)!

When you’re interfacing two devices through RS232, the transmitting (or TX) pin on one end needs to connect to the receiving (or RX) pin on the other end. And vice versa! Essentially, the TX/RX lines have to cross eventually.

Looking at the schematic of the RS232 click:

RS232 Click Schematic _ with comments

this conditions seems to be satisfied! So that when you connect it directly to the PC’s COM port without any cable – it should work! Because I needed a cable (due to obvious access restrictions), I used a pass-through cable (essentially a pin-to-pin connection) with a male connector on one and a female connector on the other side – for both RS232 click board!

After scratching my head for a while, I ended up using a cross-connected cable (essentially a cross between pin 2 on one side and pin 3 on the other side of the cable’s connectors – and vice versa!) for the weight scale to my IoT device interface and kept the other cable. This made no sense as I am essentially double cross-connecting the TX/RX lines!? I am definitely missing something here but have no intentions of going any further than this. Maybe it’s just the weight scale indicator?

My second TODO item on the list was to sort out the WiFi connectivity part. This was pretty straight forward using the provided examples – regardless if you use Energia IDE or Code Composer Studio (with TivaWare)! All of this will be made available on my BitBucket repo once I’m completely finished.

The third item was to “marry” the RS232 and the WiFi parts. And this is when I came to a temporary stop! The reason being: I failed to do the most basic thing which is RTFM! Or in more polite terms Read the Documentation!

An extract (of the pin mapping) from page 9 and 10 of the CC3100 manual:

IoT - pin assignment _ CC3100 board

My pin mapping:

IoT - pin assignment _ Tiva C board

Pin conflict!

IoT - pin assignment _ Conflicts

I naively thought I could just use any pin I wanted 🙂 guessing the booster pack works on thin air!? 🙂 The +3.3V and GND pins are OK – quite expected – but the other three (nHIB vs. U5_RX, SPI_CS vs. LED_G and WLAN_LOG_TX vs. U2_RX) definitively not!

Nevertheless, I need to sort out this without going in a totally different direction and abandon my intention to experiment with my Tiva C launchpad.

So this is my plan (impractical/silly or not):

I will use a second (and a smaller) micro for the RS232 interfacing only, and use the Tiva C board for the WiFi connectivity and driving of the indicator LEDs. I could use any microcontroller here, but I happen to have an extra MSP430 from TI: one UART (which I will be using to interface to the scale), a couple of pins to interface to the PC (by essentially employing the bit banging technique or emulating the serial communication channel) and SPI to interface this smaller micro to the Tiva C board.

The Tiva C board might have been an overkill since the beginning (and now this), but it seems my project has taken a path of its own, so I decided to follow it!