Screen Shots of a 'System' install

I have been using the soon-to-be-available simple 2" dash display, and today took some snap shots.  On Viking Star the VSR Alternator Regulator connected locally to the alternator and working in conjunction with an RBM (Remote Battery Monitor) .  From the VSR Alternator Reference Guide, here is how things are wired up:

Example 5:  System Installation  w/Alternator Current Measurement

 


With this setup the Alternator Regulator is wired locally at the alternator; monitoring its voltage, current, and temperature.  The Battery Monitor is back at the battery monitoring its voltage, current, and temperature.  A single CAT-5 cable is ran from the engine room back to the battery.  To connect the simple Dash-Display all I needed to do was continue this CAT-5 cabling from the VSR Alternator Regulator up to the dish display.  While running I took these photos:

Shown here are two screens, one for the Battery and one for the Alternator.  (Note, all these screens were automatically created by the simple Dash Display, no setup needed - just plug in the CAT5 cable).  Some details I wanted to point out:

• A key value of the RBM (Sensor Extender if you will) is that it simplified wiring.  Only a single CAT5 needs to be routed back from the Engine room.  The VSR Alternator Regulator is provided true Battery information in this way.
• This leaves the Alternator sensing wires to sense the Alternator, voltage and current.
• And to install the simple Dash Display, only a CAT-5 cable was needed.  No need to run ANOTHER set of sensing wires to the battery and alternator.

While running I also want to point out some details shown on the screen-shots above:

1. Note how the Battery Voltage is 14.4v (its target) while the Alternator voltage is a bit higher at 14.5v.  This is because of voltage drop of high current over the battery cables.
2. Note also how the battery amps are higher then the alternator output.  This is because I also have solar panels installed which are not (presently) participating in the systems communications network.

Fun and interesting if you like to watch things like this -- but one thought related to point #1 above:  If while monitoring you see the voltage difference between the battery and the alternator starts increasing, this is an indication of a wiring failure in the high current wires.   Being able to monitor and catch this is one safety ability a Systems Approach allows.

A look at SeedStudio USB-CAN Analyzer API

Securing a CAN adapter is somewhat a challenge.  There are several available, commercial as well as open source - with their costs starting at $50 and quickly raising higher.  So it was with great interest that these little guys started showing up on Ebay:

USB-CAN Analyzer Dongle  (Note V7.00)

Costing around $25, they looked to be a promising little device to use, and for some reason they have somewhat wide availability.  Including SeedStudio who offers them for a reasonable price:   https://www.seeedstudio.com/USB-CAN-Analyzer-p-2888.html     I was able to purchase one through Mouser for the same price.  (SeedStudio branded).  And of note:  the one I have matches the photo, including the V7.00 revision.

However, the documentation is very lacking, and what is there is flat wrong.  It does come with a Windows program that one can use to look at CAN messages, as well as send out some packets - but if you want to intercept the USB port and use it for your own programs, well . . . .

So I did a little snooping.  Using a COMM monitoring program I have been able to decipher the ASCII commands to and from the little USB dongle for several of the key functions covering basic config, sending and receiving of packets.   Perhaps some official (and correct) documentation will come available, until then I hope this guide can help some folks.

BASICS:

The USB dongle connects to the USB port via a QinHeng CH340 USB2 serial to USB adapter.  Once your OS has loaded the needed driver a virtual COM port is created.

CONFIGURING

The Configure command is a 20 character string with the following format:

Byte	Use	Value	Notes
1	START TOKEN	0xAA	Fixed value
2	COMMAND	0x55	Configure
3	?	0x12
4	SPEED	0x01 =  1Mbps    0x02 = 800Kbps 0x03 = 500Kbps 0x04 = 400Kbps 0x05 = 250Kbps 0x06 = 200Kbps 0x07 = 125Kbps 0x08 = 100Kbps 0x09 =  50Kbps 0x0A =  20Kbps 0x0B =  10Kbps 0x0C =   5Kbps
5	FRAME TYPE	0x01 = Std 0x02 = Extended
6	FILTER	MSB	Example:  0x12345678   --> 0x78
7			0x56
8			0x34
9		LSB	0x12
10	MASK	LSB	Example:   0xFCBA987   --> 0x87
11			0xA9
12			0xCB
13		MSB	0xFE
14	MODE	0x00 = Normal 0x01 = Loopback 0x02 = Silent 0x03 = Loopback + Silent
15	?	0x00 or 0x01	At one time I noted this being 0x01, not sure why…
16		0x00
17		0x00
18		0x00
19		0x00
20	CHECKSUM	Calculated = 8-bit sum of Bytes 2..18

 Example, 250Kbps, Extended Frame, no filtering / no mask, Standard mode. (aka, what the regulator uses):  AA 55 12 05 02 00 00 00 00 00 00 00 00 00 01 00 00 00 00 1A     

SENDING  DATA PACKETS:

The format for sending a packet is variable length with no terminator.   It again begins with the 0xAA value, and follows these tables:

Sending STD frame:

Byte	Use	Value	Notes
1	START TOKEN	0xAA	Fixed value
2	COMMAND	Bits 6..7 = 11	Transfer Packet
	STD/EXT	Bit 5     = 0	Standard message
	?	Bit 4     = 0
	LENGTH	Bit 0..3	Number of data bytes being sent
			Example: Sending 6 bytes:  0xC6
3	ID	LSB	Example:  ID = 0xBA98  --> 0x98
4		MSB	0xBA
5	DATA	Data byte 1	Data packet.  Transmit only the number of characters you want to send. (Matching LENGTH above)
6		Data byte 2
7		Data byte 3
8		Data byte 4
9		Data byte 5
10		Data byte 6
11		Data byte 7
12		Data byte 8

Sending EXT frame:

Byte	Use	Value	Notes
1	START TOKEN	0xAA	Fixed value
2	COMMAND	Bits 6..7 = 11	Transfer Packet
	STD/EXT	Bit 5     = 1	Extended message
	?	Bit 4     = 0
	LENGTH	Bit 0..3	Number of data bytes being sent
			Example: Sending 6 bytes:  0xE6
3	ID	LSB	Example:  ID = 0xFEDCBA98  à--> 0x98
4			0xBA
5			0xDC
6		MSB	0xFE
7	DATA	Data byte 1	Data packet.  Transmit only the number of characters you want to send. (Matching LENGTH above)
8		Data byte 2
9		Data byte 3
10		Data byte 4
11		Data byte 5
12		Data byte 6
13		Data byte 7
14		Data byte 8

RECEIVING DATA PACKETS:

 Receiving is the same as Sending but includes a 0x55 prefix.  Note also, I am inferring the STD packets as I only captured EXTENDED frames.  Again, packets are variable length with no terminator.

Byte	Use	Value	Notes
0	?	0x55	Prefix value?  Help to re-sync??
1	START TOKEN	0xAA
2	COMMAND	Bits 6..7 = 11	Transfer Packet
	STD/EXT	Bit 5     = 0	Standard message
	?	Bit 4     = 0
	LENGTH	Bit 0..3	Number of data bytes being sent
			Example: Sending 6 bytes:  0xC6
3	ID	LSB	Example:  ID = 0xBA98  --> 0x98
4		MSB	0xBA
5	DATA	Data byte 1	Data packet.  Transmit only the number of characters you want to send. (Matching LENGTH above)
6		Data byte 2
7		Data byte 3
8		Data byte 4
9		Data byte 5
10		Data byte 6
11		Data byte 7
12		Data byte 8

Byte	Use	Value	Notes
0	?	0x55	Prefix value?  Help to re-sync??
1	START TOKEN	0xAA
2	COMMAND	Bits 6..7 = 11	Transfer Packet
	STD/EXT	Bit 5     = 1	Extended message
	?	Bit 4     = 0
	LENGTH	Bit 0..3	Number of data bytes to receive
			Example: Receiving 8 bytes:  0xE8
3	ID	LSB	Example:  ID = 0x 19F21280  --> 0x80
4			0x12
5			0xF2
6		MSB	0x19
7	DATA	Data byte 1	Data packet (Matching LENGTH above)
8		Data byte 2
9		Data byte 3
10		Data byte 4
11		Data byte 5
12		Data byte 6
13		Data byte 7
14		Data byte 8

I hope folks find this of some interest and help.  If you have any addition input, please add to the comments below.  I have this detail in a .wrd file and can send it to anyone who is interested to review / edit and/or correct.