administrators

Here's an internal build of IO Ninja for arm64:

https://tibbo.com/downloads/archive/ioninja/.internal/prerelease/ioninja-5.7.1-c-linux-arm64.tar.xz

The ioninja-hwc introduces two new parameters:

--split-size <bytes> and --split-time <seconds>

Both options can be used together; in this case, the splitting will occur based on whichever condition is met first. Both options support reasonable suffixes, e.g., --split-size=10M, --split-time=6h, etc.

Let me know if this works for you!

If this is something you could add "for free" to your new development, great! If not, well, I think that this is no a common case, in fact, I found it very weird (but "real" indeed).

Yes, it comes for free, so we'll have a setting for that!

if possible/feasible/reasonable, consider the options of splitting by size (eg. each "n" MB) and by time (eg. each "t" minutes). It is just an idea... perhaps it seems more logic just consider the size, but -eg. for my case- it is more convenient to have captures of info more or less time aligned (eg. daily aligned... in fact, I am currently splitting them each 6 hours)

Good point! Let's have settings for both!

consider the option of being "transparent" when power-off...

Oh yes, I agree! This is absolutely one of the must-have features for the next generation of Ethernet Tap. Disconnecting power from the tap should not disrupt the existing link.

Well, then have to add help tooltips to every other setting, too, for consistency... Which could be the right thing to do, actually

In this particular case, however, I'm kinda inclined to simplify and drop this setting altogether (use hex-line-size / 2 for this special dual-hex-view mode).

Hello,

The Serial Tap for IO Ninja (and the majority of standard USB-to-Serial adapters) does not support 9-bit UART communications. The upcoming Serial Tap Pro (to be released early next year) will support this feature natively, but in the meantime, here’s a workaround.

First, some background. The most common use case for the 9th bit in UART is marking the address byte in some industrial automation protocols. This important optimization enables slave nodes to inspect only the first (address) byte; if the address does not match, the slave can safely ignore all subsequent bytes until the next address byte (i.e., the next UART frame with the 9th bit set).

In these scenarios, the 9th bit is clear for most payload bytes and set only for address bytes. To monitor such communications using a Serial Tap (or a USB-to-RS485 adapter), use the settings as follows:

Baud rate: <specify-the-correct-baud-rate>
Data bits: 8
Parity: Space
Stop bits: 1

With these settings, address bytes will generate PARITY errors (the parity is set to "space," but the parity bit is 1), while the rest of the traffic will remain free of line errors.

Reporting of line errors is inherently asynchronous, so the PARITY errors won't necessarily align precisely with each address byte (BTW, Serial Tap Pro will address this, too, and line errors will be byte-precise). Still, you should see a PARITY error somewhere around the address byte.

Hope this helps; let me know if this workaround works for you!

Hello,

It's not very clear what you mean by "automatically labeling log files according to the session name or device ID". When you create a new IO Ninja session, the log is stored in a temporary file. When you save the session, you explicitly specify a directory name to store the session data (or a single file name if you only need to save the log file) -- so you are the one picking the file names.

If you need to post-process the log files externally, you can do it in any language of your choice (Python, JavaScript, C, etc.) The .njlog file format is very simple. A brief overview can be found here: https://ioninja.com/doc/developer-manual/logging-engine.html) and all the internal structures are open-source; see scripts/api/log_RecordCode.jnc and scripts/api/log_RecordFile.jnc for all the relevant declarations.

Let me know if you have any follow-up questions regarding the file format.

Apologies for the inconvenience.

Please restart the Pipe Monitor session and set the Filter to "None" if you don't need to filter by name. Alternatively, you can set the name wildcard to * (i.e., an asterisk).

Tech details:

The latest release of IO Ninja contains a regression that results in an exception when setting an empty wildcard as a filter; the log engine remains suspended after this exception, thus resulting in the "empty log" you saw.

Here's how to fix it (until the next release takes care of it):

1. Open <ioninja-dir>/scripts/common/log_MonitorFilter.jnc in any text editor
2. Search for MonitorFilter.setFilter
3. Add the following snippet right before processing the wildcard string:

switch (filterKind) {
case MonitorFilterKind.FileName:
case MonitorFilterKind.ProcessName:
	// <<<<<<<
	if (!filter) {
		m_filterKind = MonitorFilterKind.None;
		break;
	}
	// >>>>>>>

Save the script and restart the Pipe Monitor session (no need to restart the app).

Please let me know if it works for you.

This was done for the I2C/SPI Tap. The IO Ninja log engine supports this special dual-hex view for SPI which looks like this:

But I totally see how this could be confusing -- it's only relevant to this single plugin and a single mode in this plugin!

Maybe, we should remove this setting completely and simply calculate it as hex-line-size / 2?

Hello again, Josep,

Yes, it's in the works, but it's currently sidelined in favor of the upcoming release of Serial Tap Pro -- which I mentioned in my response to your post about the TTL signal inversion.

Full-scale development of the new generation of Ethernet Tap will be resumed after that.