Quantcast
Channel: Posts on JeeLabs
Viewing all articles
Browse latest Browse all 232

SMA Solar readout - part 2

$
0
0

(Part 2 of the SMA Solar readout series)

Here is the hardware, with its three main components - LCD, µC, and Bluetooth:

The bottom is wired up using my favourite one-off soldered-kynar-wire technique:

The cutout leaves the BT module’s PCB antenna exposed for 2.4 GHz RF signals.

There’s not much to it, really. So let’s move on to the software side of things…

The first challenge, as always with a new board, is to get Mecrisp Forth uploaded into its flash memory. See this weblog post for links to different ways to get there.

Since it’s more or less a standard low-end F103 board, I’ve uploaded thealways.fs, board.fs, and core.fs files from the g6s area in the Embello repository. This provides a lot of general-purpose µC board functionality out of the box, permanently added to flash memory on top of Mecrisp. Lots of drivers, most of which are not used here, but also some startup configuration and very useful GPIO primitives.

With all this loaded, we have ≈ 22K flash and 17K RAM free, plenty for this app.

The next step is to connect to the Bluetooth module, and to pair it with the actual SMA inverter. There’s an IRQ-based UART2 driver inEmbello, which helps make sure we won’t lose any incoming characters.

One somewhat tricky part is pairing. For that, the HC05 module needs to be placed in command mode (there’s a “KEY” I/O pin for that), at which point it will accept “AT” commands. About two dozen commands must be sent to permanently store pairing information inside the HC05 module.

But there’s a catch: some commands will depend on the Bluetooth address of the SMA inverter, so I had to pick that up from the returned output and manually insert it into the source code before trying again. After a few iterations (once the bugs were ironed out), it all started working:

  ok.
bt-pair 10 OK
11 +VERSION:2.0-20100601
OK
12 OK
13 OK
14 OK
15 OK
16 OK
17 OK
18 OK
19 OK
20 +STATE:INITIALIZED
OK
21 OK
22 OK
23 OK
24 +INQ:80:25:A4EC14,1F04,FFA8
OK
25 +RNAME:SMA001d SN: 2130086382 SN213008
OK
26 OK
27 OK
28 +ADDR:2013:10:220486
OK
29 +MRAD:80:25:a4ec14
OK
30 OK
31 OK
32 +STATE:PAIRED
OK
 ok.

Unfortunately, this will have to be repeated and re-uploaded to get the other SMA unit working at my friend’s place, since I’m too lazy to code thisonce-only task in Forth.

Once paired, this code never needs to be executed again. We can now burn it into flash memory and move on to the next step:

  ok.
compiletoflash  ok.
!s sma.fs
  ok.

And this is where it gets a bit nasty…

The code to calculate checksums and to generate the different packets we need to send to the SMA, is extremely messy. It’s basically a port of the original (already messy) C code. In Forth, we can perform this logic with very few lines of code, but it does not really help clarify what’s going on for the casual and unsuspecting reader …

All that logic for generating and decoding packets, for “logging in” on the inverter, and for getting the readings can be found in thesma2.fs file. Enter at your own risk…

A few days of hacking and head-scratching ended with this succesful readout:

  ok.
try
ini 2010 ms
login: 0 1138 ms
power: 849 W, 129 ms
yield: 6798 W, 126 ms
total: 17965050 W, 121 ms
 ok.

There’s a debug mode to display all packets, which can be enabled with “1 debug !”.

The closing part of the software is to pull everything together, format the results to show up nicely on the LCD, and enable the hardware watchdog, so that the unit will recover from any connection failures.

This logic can be found in theapp.fs file and should be much easier to follow.

Having the hardware watchdog running (which times out if not triggered within 13 seconds) means that the code can be fairly sloppy in terms of error handling. Also, on a restart, we check the reason and if it was due to the watchdog,“C?” is displayed in the lower left-hand corner. A successful readout will then clear this again later.

Note that this code needs to auto-start on power-up, without preventing development mode when a serial cable is attached. This is implemented with therx-connected? and unattended words (similar to aJNZ):

: init init unattended main ;

As last step, thefinal.fs code is used to re-flash the µC board with a complete setup:

<<<core>>>
compiletoflash
( app start: ) here dup hex.

include sma.fs
include sma2.fs
include lcd.fs
include app.fs

( app end, size: ) here dup hex. swap - .

As you can see, this app uses ≈ 8.5 KB flash:

  ok.
!s final.fs
1> final.fs 3: <<<core>>>
Finished. Reset ?Mecrisp-Stellaris RA 2.3.9 for STM32F103 by Matthias Koch
64 KB <g6s> D437BB1C ram/flash: 17020 22528 free ok.
1> final.fs 4: cr
 ok.
1> final.fs 7: ( app start: ) 0000A800  ok.
8> app.fs 101: Redefine init.  ok.
1> final.fs 14: ( app end, size: ) 0000C93C 8508  ok.
hello 64 KB <g6s> D437BB1C ram/flash: 16688 14020 free  ok.

That’s it. Next week: the finishing touch!


Viewing all articles
Browse latest Browse all 232

Trending Articles