Currently, IAS (in-app-script) can only control the underlying session via:

• connect()
• disconnect()
• transmit(p, size)

Fine-tuning of the sessions configuration is currently not possible from IAS. But we plan to add this capability in the near future.

Each session class will export a public IAS interface (e.g., a serial session will have properties to query and control baud rate, parity, status lines, etc.) Then, IAS should be able to access this interface via a global constant g_session (or something like that).

Hello Maxim,

To borrow a capability, you need:

1. Be a part of a workgroup;
2. Your workgroup must have at least one unused seat of this capability.

Then, from the "Capabilities" page, click on this particular capability, and you should see a "BORROW" button at the bottom of the page (like on a screenshot below):

Apologies for the delayed reply... Still, better late than never

Alas, currently, there's no support for remote monitoring via Serial Taps -- fiddling with ioninja-server won't cut it... However, it's on our immediate TODO list; we are working on a major update scheduled for the beginning of 2022 which -- among many other things -- will allow controlling Serial Taps and other IO Ninja hardware sniffers connected to remote ARM-based Linux boxes (such as Raspberry Pis).

If waiting for the update is not an option, I suggest writing your own program which would read from a Serial Tap using libusb (or any other low-level USB framework available in the programming language of your choice) and dump the captured data into a file.

The low-level details of USB communication with a Serial Tap (USB VIDs/PIDs, IN/OUT endpoints, packet formats, etc) can be checked in the open-source implementation of the official Serial Tap plugin (see file scripts/plugins/SerialTap/SerialTapSession.jnc). If you are familiar with C-family languages (C, Java, JavaScript, etc) you should be able to read and understand pretty much everything. And of course, feel free to ask any implementation-related questions here.

Hope this clarifies the issue.

Currently, IAS (in-app-script) can only control the underlying session via:

• connect()
• disconnect()
• transmit(p, size)

Fine-tuning of the sessions configuration is currently not possible from IAS. But we plan to add this capability in the near future.

Each session class will export a public IAS interface (e.g., a serial session will have properties to query and control baud rate, parity, status lines, etc.) Then, IAS should be able to access this interface via a global constant g_session (or something like that).

Please read the introduction to the new licensing model here: https://ioninja.com/capabilities-intro.html

In particular, the section "Have a License?" outlines how to reuse old licenses in IO Ninja 5.

Also, Serial Taps (and all other IO Ninja hardware taps) do not require any paid capabilities and should work just like before, even with fewer restrictions. With IO Ninja 3, to use a Serial Tap, one had to possess a license. Now, it's not required -- for example, you can freely share Serial Taps with your friends.

Sure. The basic idea is to listen for new log records and update your variables holding the state of RTS/CTS lines accordingly. You would need SerialLogRecordCode.PortOpened to get the initial line state on port open, SerialLogRecordCode.RtsChanged to track RTS changes, and SerialLogRecordCode.StatusLineChanged to track CTS changes.

In the sample below, I simply print the states of those lines to the session system log (Menu -> View -> System Log). Feel free to change it according to the requirements of your script.

import "io_base.jncx"
import "io_Serial.jnc"
import "Serial/SerialLogRecordCode.jnc"

bool g_rts;
bool g_cts;

void onLogRecord(
	uint64_t timestamp,
	uint64_t recordCode,
	void const* p,
	size_t size
) {
	switch (recordCode) {
	case SerialLogRecordCode.PortOpened:
		SerialOpenParams const* params = (SerialOpenParams const*)p;
		g_rts = params.m_rts;
		g_cts = (params.m_statusLines & io.SerialStatusLines.Cts) != 0;
		printf("Initial RTS: %d CTS: %d\n", g_rts, g_cts);
		break;

	case SerialLogRecordCode.RtsChanged:
		g_rts = *(bool const*) p;
		printf("RTS changed: %d\n", g_rts);
		break;

	case SerialLogRecordCode.StatusLineChanged:
		SerialStatusLineChangedParams const* params = (SerialStatusLineChangedParams const*)p;
		if (params.m_mask & io.SerialStatusLines.Cts) {
			g_cts = (params.m_lines & io.SerialStatusLines.Cts) != 0;
			printf("CTS changed: %d\n", g_cts);
		}
		
		break;
	}
}

Could you please share your wiring diagram? Or a photo of how you connect the tap?

For RS485 half-duplex (two-wire), you need to connect either the (RX+/RX-) pair or the (TX+/TX-) pair. The only difference it's going to make is how the data will be called in the IO Ninja log -- RX or TX. For RS485 full-duplex (four-wire) -- which is far less common -- you need to connect both (RX+/RX-) and (TX+/TX-). But you definitely don't need two taps to sniff a single serial link.

Oh, so you are using a Serial Tap for IO Ninja; not a generic dual-COM serial tap.

Then you need to use a dedicated "Serial Tap" plugin (not "Generic Serial Tap").

Generic serial tap reads from two ports at the same time -- one port obtains RX, CTS, DSR; the second one obtains TX, DTR, RTS. Oftentimes, only TX and RX are required -- it simplifies the wiring. There are various over-the-counter dual-COM taps available; you can easily solder (or build on a breadboard) your own one, too.

The log error message says "ports A and B" while the toolbar refers to those ports as "DTE" and "DCE". This is confusing, I agree. We will change the port names in the log to "DTE" and "DCE" for consistency.

Hopefully 1 last questions - you are calculating the CRCs and reporting whether they are accurate/correct - do you just run through a bunch of different CRC algorithms at the start of a capture to try and work out which is the correct one ?

Modbus RTU is using CRC16 (ANSI) with the seed value of 0xffff. You can see the Modbus checksum of any data block in the "Checksum calculator" of the Information pane on the right. Select a range of data, and it will be instantly calculated.

The code should look something like this:

uint16_t modbusChecksum = crc16_ansi(p, size, 0xffff);

The implementation of crc16_ansi is in scripts/common/crc16.jnc

Perfect thanks !!! Now i am getting a good decode of what is going on

Glad to hear it works now!

Is there anyway to export the Hex Strings (without decode) into a text file

Yes, you can export your log as a text file (Menu -> File -> Save Log As...) at any time.

I often find it easier when decoding unknown devices (in terms of registers) to look for patterns and things that are constantly changing to give a hint as to what the data could represent.

If you want just the pure data without annotations added by Modbus Analyzer -- remove the Modbus Analyzer layer, and you will get back to the original log. Modbus Analyzer (as well as other protocol analyzers) does not destroy the original log, so it's totally reversible.

Another option to get to the raw data is to post-process the original .njlog file. It will be more efficient than parsing a hex view inside a text file. The .njlog file format is open-source (log file structure definitions are in scripts/api/log_RecordFile.jnc), so you can use any programming language of your choice.

An example of decoding *.njlog files can be found in scripts/plugins/ReplayLog/ReplayLogLayer.jnc, function ReplayLogLayer.readLoop(). This plugin reads a log and "replays" TX or RX data with respect to inter-packet delays. It's probably not exactly what you want, but it should give an idea of how to "walk" across a raw .njlog file to process the captured data.

Your decode window etc is brilliant i must say though !!
Great product

Thank you! We work hard to make our product as versatile and convenient as possible, so I really do appreciate such feedback