PV diversion > mk2pvrouter: co.uk to com?

Hardware
1

Hello

It might be that I will look for a PV diversion at my parents place. And ‘Mk2 PV Router’ seems like a good place to start. But now I read at https://mk2pvrouter.co.uk/:

Since January 2023, the Mk2 PV Router project has been operated by new owners who are in France.
This original website has been retained for reference purposes.

I guess the new owners operate from https://mk2pvrouter.com/? It is a website only in French, not in English. But I can’s seem to find any more information about the ‘why’ Robin Emly stopped. Also Diverting surplus PV Power, by Robin Emley — OpenEnergyMonitor 0.0.1 documentation still refers to “This new venture of mine is fully described at www.Mk2PVrouter.co.uk where there is a Shop…”

As far as I remember Robin Emly is/was active on this forum. Are the new owners active here? Where is the project heading? Anyone any more background information?

2

You are correct, Robin has transferred all new business to new owners in France, who I understand have plans to continue and expand the operation. Robin will continue to maintain the reference material at the UK website for the foreseeable future, and I believe he might have a limited stock of spares for repairs - although most parts continue to be available from the original suppliers.

I have not seen any sign of the new owners here, however they do have a good command of English, if you need to contact them (in English). You can still contact Robin by email.

1 Like
3

Indeed so, and my Shop page is still there in a cut-down form. I do still have most parts for Mk2 Router systems and these are available for anyone who needs them. In practice, this opportunity will probably only be of relevance to constructors in the UK.

After my Mk2 Router design was featured in a couple of Youtube videos in French, the rate of orders from France increased to more than I was able to cope with. I needed to wind down this operation and was thankfully able to hand over the business to an enthusiastic young couple in France.

To sell the Mk2 Router in a fully pre-built form, CE marking is required which is a major undertaking. As a step in this direction, the new owners can supply a partially assembled system where the fabrication of the box and all internal wiring has been prepared in advance. Only the circuit boards need to be assembled by the end customer. A fully built version with CE marking is planned for later in the year.

4 Likes
4

Old thread bump…
Robin, Can the sketches be updated to work with the new LowPowerLab standard?
This is to capture the data into an EmonPi2./
If so, a pointer would be nice…

5

Do you have the RFM12B radio in your Mk2, or the more powerful RFM69CW? You need the latter, because OEM decided to encrypt the r.f. data and only the RFM69CW can do this - it’s in silicon and the ATMega in your Mk2 hasn’t got the power to do it and divert at the same time. If you can swap the r.f. module, then I can tell you (and Robin) how to change the sketch. If you can’t physically desolder the module without risking damage to your p.c.b, I can change one of the OEM libraries to be compatible with the LPL message format but you’d need to turn off encryption in your emonPi2 and anything that communicates with it by radio (or change back to using the JeeLib message format which doesn’t use encryption).
This might help explain things: https://docs.openenergymonitor.org/electricity-monitoring/networking/index.html, particularly this: 433MHz Radio Format vs Device — OpenEnergyMonitor 0.0.1 documentation

6

Robert,
Hmm, that will take a bit of dismantling…
It does have the radio, but offhand I don’t know which one.
My unit is a good few years old now.
Thanks

7

It’s almost certainly the RFM12B, because I think Robin has never used the RFM69CW; but it must be worth looking.

8

A little hope here on RFM12B vs. RFM69CW …

The Mk2 PV router (English version) kit that I ordered in January 2023 came with an RFM69CW …

I don’t know when Robin changed from supplying the RFM12B to the RFM69CW. His parts list includes both the RFM12B and the RFM69CW.

9

Robert,
I have installed a RFM69CW, so if you could show me the changes to make to a sketch that would be great…
Thanks

10

Which sketch are you using? Though they’ll all be much the same, it will be easier if I know which one.
And you want the LPL library with encryption to work to an emonPi2 (per Post no.4)?

11

I believe my original sketch was “Mk2_RFdatalog_6”, but I also have the latest download from the French site “PVRouter_Mono_2Charges_EnregistrementViaRF”, so I’m not worried either one!
Yes, to work with the EmonPi2.
Thanks

12

I don’t know that the French software is compatible with Robin’s hardware - I do know they were embarking on a major redesign, I don’t know any more than that. I’ll do (or tell you) the changes for “Mk2_RFdatalog_6”.

[Edit]
The change for Mk2_RFdatalog_7:

  • July 2022: updated to Mk2_RFdatalog_7, with this change:
    • the datalogging accumulators for grid power, diverted power and Vsquared have been rescaled
  • to 1/16 of their previous values to avoid the risk of overflowing during a 10-second
  • datalogging period.

I’ve got both - do you want the _7 version or stay with the _6?

13

May as well have the _7 version…
Cheers.

14

I don’t have a Mk2 PV Router to test it on, so I’ve had to fudge the software.

Immediately before the end of setup( ), I added

while(1)  
  	{
		// dummy data to prove LPL
		tx_data.powerAtSupplyPoint_Watts = 678; // import = +ve, to match OEM convention
		tx_data.divertedEnergyTotal_Wh = 2345; // always positive
		tx_data.divertedPower_Watts = 123; // always positive
		tx_data.Vrms_times100 = 24500;
		tx_data.temperature_times100 = 1456;
	
		send_rf_data(); 
		Serial.println ("Tx");
		delay(5000);
	}

which inserts some recognisable data and uses exactly the same transmit function as loop( ). It seems to work for me.

Mk2_RFdatalog_7a.ino.zip (15.1 KB)

All the changes are associated with the “LPL” preprocessor definition, so it should be fairly easy to see what I’ve added. I didn’t test the JeeLib option, so if you do change back at some point, beware, you might find I got it wrong. You could always download the original Mk2_RFdatalog_7.ino from Robin’s site, or I’ll have it if he shuts the site down. I’ll send him a copy.

You’ve probably already got this for emonHub (no changes):

    [[10]]
        nodename = Mk2PVRouter
        [[[rx]]]
            names = powerAtSupplyPoint_Watts, divertedEnergyTotal_Wh, divertedPower_Watts, Vrms_times100, temperature_times100
            datacodes = h, h, h, h, h
            scales = 1.0, 1.0, 1.0, 0.01, 0.01
            units = W, Wh, W, V, C
15

Robert, thanks for that and finally got round to swapping the module and programming the unit.
When booting it sends this through the serial,

Sketch ID:   Mk2_RFdatalog_7.ino

ADC mode:       free-running
Output mode:    anti-flicker
  offsetOfEnergyThresholds  = 0.10
powerCal_CT1, for grid consumption =      0.0620
powerCal_CT2, for diverted power  =      0.0620
voltageCal, for Vrms  =      1.0000
Anti-creep limit (Joules / mains cycle) = 5
Export rate (Watts) = 0
zero-crossing persistence (sample sets) = 2
>>free RAM = 804
  capacityOfEnergyBucket_long = 2903225
  lowerEnergyThreshold_long   = 1161290
  upperEnergyThreshold_long   = 1741935
>>free RAM = 804
----
RF capability IS present, freq = 433 MHz
RF with LPL failed to initialise.

and then nothing.
Supply to the module is OK at 3.3v
Anything else I can check?
Thanks

16

As I mentioned, it worked for me on an emonTx V3, and looking at the library, a failure to initialise means the RFM is not communicating with the ATMega. So I think it’s the data lines SCK, NSS, MOSI and MISO that you need to check.

You have orientated it correctly - the r.f. out is nearest the bunch of mall capacitors?

17

Robert,
Everything checks out fine, and yes it is orientated correctly…

18

What exactly? Have you checked continuity of the tracks between the RFM and the ATMega? (My thinking - a broken track/pad when you removed the RFM12B).

This is the library where I think it’s failing. The initialise() function must return false to trigger the “RF with LPL failed to initialise.” message:

  spi_init();
  
  uint32_t start = millis();
  uint8_t timeout = 50;
  do writeReg(REG_SYNCVALUE1, 0xAA); while (readReg(REG_SYNCVALUE1) != 0xaa && millis()-start < timeout);
  if (millis()-start >= timeout) return false;
  start = millis();
  do writeReg(REG_SYNCVALUE1, 0x55); while (readReg(REG_SYNCVALUE1) != 0x55 && millis()-start < timeout);
  if (millis()-start >= timeout) return false;

It’s trying to write a value into a register in the RFM, and read it back. It’s either getting the wrong value back or nothing. We don’t know which of the two is failing or why, but it doesn’t really matter - it won’t do anything until it can communicate.

19

Continuity between the ATMega (via resistors) and the RFM, also between the 3.3v supply and the RFM and ground, so basically all the connections to the RFM are fine.
The RFM is soldered with wire links as the PCB layout is too wide for the module so no pads are involved in the module soldering.

20

I knew Robin had done it that way originally, on purpose to facilitate changing the RFM, but I didn’t know offhand if he’d continued to do it on all the boards. I’d got to ask.

You’ve obviously compiled the sketch without errors. I’ll think about this a bit more later, but at the moment I’ve run out of ideas.