Charging EPEVER Solar UP3000-M6322 with an unclean non-inverter based generator

Below is an oscilloscope (using differential voltage probe and current probe) picture showing the voltage and the current when charging from the main supply.

Then below is how it looks like when charging at maximum power (30A at 24V) from a Stanley SG 2400 generator (non-inverter). As we can see, the voltage looks quite distorted. Also the current looks different, and does not go as high as in the case when charging from the utility supply.

The last picture shows what happens when suddenly the plug to the EPEVER inverter is pulled out of the socket.

Overrun or Underrun due to two Blocks in a GNU Radio Flow Graph that are no 100 % in Sync

I have noticed a problem when there are several blocks in a flow graph that have a fixed rate. This is typically the case if a Software Defined Radio (SDR) is the source in the flow graph, and the audio device on the computer is the sink of the flow graph. If the clocks on the SDR and the audio device are not in 100% sync (which is nearly always the case), they will drift and eventually there will either be an underrun (not enough samples produced for the audio device) or an overrun (too many samples produced by the SDR). This then typically causes annoying sounds every now and then in the loud speakers.

In order to “work around” this problem, I started on a new block to analyze the situation. The idea is to have a fairly big FIFO in a block and then monitor the fill rate of this FIFO. The block can be found here: https://github.com/rubund/capture-tools/blob/master/gr-capture_tools/lib/xrun_monitor_ff_impl.cc

It will print out the fill rate of the FIFO. When starting up, it tries to fill it to about 50% before passing the real samples on to the output. It produces zeros until it reaches 50% fill rate. Then if the fill rate later drops below 30%, it halts and fills up to 50% again before starting to pass samples over.

The plan is to later automatically inject single samples here and there to make the problem almost invisble/inaudible.

Z-Wave Packets

When turning on one switch:

Mag: -30.15, Time: 2018-06-17 13:32:27 [f0d66dec2c0141060d042501ff100000..]
Mag: -23.62, Time: 2018-06-17 13:32:27 [f0d26dec2c0403060a018e00..]
Mag: -26.69, Time: 2018-06-17 13:32:27 [f0d66dec2c0441090d012503ff1d00..]
Mag: -30.11, Time: 2018-06-17 13:32:27 [f0d66dec2c0103090a048100..]

When turning off the same switch:

Mag: -30.38, Time: 2018-06-17 13:33:45 [f0d66dec2c0141070d04250100ee00..]
Mag: -21.80, Time: 2018-06-17 13:33:45 [f0d66dec2c0403070a018f00..]
Mag: -22.77, Time: 2018-06-17 13:33:45 [f0d66dec2c04410a0d01250300e100..]
Mag: -30.52, Time: 2018-06-17 13:33:45 [f0d66dec2c01030a0a04820000..]

Turning on a second time:

Mag: -30.77, Time: 2018-06-17 13:35:16 [f0d66dec2c01410a0d042501ff1c00..]
Mag: -24.04, Time: 2018-06-17 13:35:16 [f0de6dec2c04030a0a018200..]
Mag: -28.45, Time: 2018-06-17 13:35:16 [f0d66dec2c04410e0d012503ff1a00..]
Mag: -30.92, Time: 2018-06-17 13:35:16 [f0d66dec2c01030e0a04860000..]

 

Turning off a second time:

Mag: -30.88, Time: 2018-06-17 13:35:55 [f0d66dec2c01410b0d04250100e200..]
Mag: -20.82, Time: 2018-06-17 13:35:55 [f0d66dec2c04030b0a01830000..]
Mag: -23.79, Time: 2018-06-17 13:35:55 [f0d66dec2c04410f0d01250300e400]
Mag: -30.78, Time: 2018-06-17 13:35:55 [f0d66dec2c01030f0a048700..]

 

By comparing the two packets used to start a “turn on” procedure:

Mag: -30.15, Time: 2018-06-17 13:32:27 [f0d66dec2c0141060d042501ff100000..]
Mag: -30.77, Time: 2018-06-17 13:35:16 [f0d66dec2c01410a0d042501ff1c00..]

We see that the only byte changing is the 8th byte (apart from the CRC). It changes from 0x06 to 0x0a. This is then probably just a number to identify a specific request.

By comparing the “turn on” packet with the “turn off” packet:

Mag: -30.15, Time: 2018-06-17 13:32:27 [f0d66dec2c0141060d042501ff100000..]
Mag: -30.38, Time: 2018-06-17 13:33:45 [f0d66dec2c0141070d04250100ee00..]

We see that the 8th byte is also changing here, but also the 13th byte. It is 0xff when turning on and 0x00 when turning off.

By comparing the first packet from the hub device with the receiver:

Mag: -30.15, Time: 2018-06-17 13:32:27 [f0d66dec2c0141060d042501ff100000..] 
Mag: -23.62, Time: 2018-06-17 13:32:27 [f0d26dec2c0403060a018e00..]

We see that the 6th byte changes (the device id), the 8th byte remains the same (request ID). The 7th byte changes from 0x41 to 0x03. This may indicate that it is an indicator of the packet type, where 0x41 is a request and 0x03 is an acknowledgement.

The end of the first packet (before the CRC) looks like 0x0d042501ff, while the second packet ends with 0x0a01. The first of the bytes is decimal 13 and decimal 10, which could be the length of the packet as of and including the CRC bytes.

By comparing the first packet from the hub device with the first “request packet” from the receiver:

Mag: -30.15, Time: 2018-06-17 13:32:27 [f0d66dec2c0141060d042501ff100000..] 
Mag: -26.69, Time: 2018-06-17 13:32:27 [f0d66dec2c0441090d012503ff1d00..]

We see that the 6th byte (device id) changes, the 8th byte changes (request id), the end of the packet changes from 0x0d042501ff to 0x0d012503ff.  The second of these bytes look like the address of the receiver. The 7th byte remains the same.

Mag: -30.15, Time: 2018-06-17 13:32:27 [f0d66dec2c0141060d042501ff100000..] 
                                        <><------><><><><><><---<><> 
                                        a b       c d e f g h   i j
a: sync word (0xf0)
b: network id
c: device id (central hub seems to be 0x01)
d: packet type (0x41: request, 0x03: ack)
e: request id
f: length of packet
g: device id of receiver
h: unknown
i: on(0xff) / off(0xff)
j: CRC

 

Transmit Packet when Pushing a Button in a GNU Radio Flow Graph GUI

In the capture_tools out-of-tree module, one block called tag_on_set_one_f and one block called file_source_on_tag can be used together to send a stream of IQ samples from a file whenever a GUI button is pushed.

Download this sample flow graph here: https://www.funwithelectronics.com/wordpress/other_data/burst_msg_source_c.grc

 

So tag_on_set_one_f will produce samples as fast a possible, and therefore a throttle block is needed after file_source_on_tag to keep the sampling rate under control.

file_source_on_tag produces zeros between “bursts”.

If you have another block which for instance produced a packet whenever receiving a stream tag, it can also be used together with tag_on_set_one_f so that when a button is pushed, a packet is transmitted.