JNIOR Tips

[Steve Guttag]

I'm a big fan of the Omron G5V series for low-current relays. The contacts are rated from 10µA to 2A (1A on the high sensitivity models).

[Bruce Cloutier]

We are going to re-tool the JNIOR enclosure. Mainly this is to both implement a better option for DIN rail mounting and to give us more flexibility to create synergistic housings in expanding the product line. There are just a couple of minor cosmetic changes. The photo here is of a 3D printed housing. There will be a quality finish on the plastic as you would imagine (looks like dark wood in the photo). I have not green-lighted the tooling and thought to get feedback from you all first if there is any. I need to get this moving at some point and soon.

We've chamfered the circumference giving a flat area by the connectors that might facilitate I/O identifying labels.

The mounting tabs are beefier and the lower one is slotted. That slotted tab can help when mounting the JNIOR on the wall. It might cause those who like to use ty-wrap mountings an issue. Is there any reason to keep it a hole? Is the slot a good idea? No?

We did not want to alter the appearance so much that it looks like a different product. It is still a Series 4.

Feel free to comment. I would hate to hear whining once these start to ship and feel that we've missed something.

We are going to rearrange the back label so the mount doesn't hide important stuff. The mount will still be an option separately ordered. Our current DIN mount is dumb (and expensive).

Here are some photos. The JNIOR is shown here with a (old) wireless adapter. This adapter is nice because it can share the power supply.

PXL_20230309_131929628.jpgPXL_20230309_131810096.jpgPXL_20230309_133321513~2.jpg

[Bruce Cloutier]

I'm a big fan of the Omron G5V series for low-current relays. The contacts are rated from 10µA to 2A (1A on the high sensitivity models).

We used Omron exclusively for the Series 3 but ran into an issue with minimum coil voltage. The relays appeared to not meet spec and Omron would not acknowledge the issue. Basically we used to drive them with a Darlington transistor pair and the voltage at the relay was down from 5V by the transistor drop. This was still much more than the minimum it stated for turn on. Some relays would not actuate. We changed the circuit to MOSFET to improve the voltage.

The relays would not close if they sat for a while (overnight). Once you got one to close it would work seamingly reliably for a while. Under the microscope there appeared to be some gummy substance inside (mold release?) and the coil needed a little extra effort to unstick the actuator. Omron (in more ways) was all stuck-up. So we went to TE and Nexem.

Kevin actually discovered that if you piled some coins on the relay that they would work reliably. He thought is was the weight. I think those aided the magnetic field and helped the coil. Omron is pricey too.

We are shipping TE Connectivity relays now and likely for the balance of the year. We shipped some 60,000 Nexem several years ago and there were no issues. Nexem is pushing for the follow-on relay contract here.

[Harold Hallikainen]

On driving relays with Darlingtons (such as the UCN5832), there IS an issue with voltage drop. A Darlington typically drops about 1.4 volts since you have to bias two transistors on (2*Vbe). I really like FET relay drivers...

[Steve Guttag]

Times change a bit, I guess. I used to use TE relays (P&B T82 series) but, at some point, Omron because easier (and cheaper) and for my standard DIP 2-form C relay, I settled on the G5V from Omron...and they offered it in 3 flavors of current required. I've never had even one, over many decades, give me any grief of any kind and always met or exceeded specs. I still use P&B relays in some applications (K10P flanged ones, come to mind but I also use Omron LY2F). For reed relays, I've used Hamlin.

You gotta go with what works in your application and provides the least (preferably no) grief. I don't think anyone has a lock on relays and in this ROHS world, all electromechanical things are suspect (no cadmium on the contacts anymore).

[Bruce Cloutier]

If you update your Series 4 to JANOS v2.4 there is the added benefit of the enhanced NETSTAT network sniffer. Previously you can use the NETSTAT -C option to generate a capture file that can be subsequently downloaded and opened with Wireshark if you have that installed. An excellent feature since WIreshark provides all kinds of analysis detail but it is not real-time in this case and a little cumbersome.

You can now watch the network real-time which is invaluable if you are concerned about say communications with a projector in response to a macro execution and need to see it to believe it. As you might know the JNIOR is always recording recent network traffic so the NETSTAT -C command can generate that capture file. Well the NETSTAT -P command applies any filter and displays the capture buffer packets right at the command line. Note that the -D option adds a dump of the packet payload. The NETSTAT -S command enters the real-time mode and packets are displayed as they happen. Hit any character to exit that mode.

Here I wanted to check for any NTP exchange since booting my JNIOR. So I used the NETSTAT -SPD combined options to display any packets matching Port 123 either from the packet capture buffer or that might be in process. After a bit I interrupted the scan.

bruce_dev /> netstat -spd 123
LAN connection active (100 Mbps)
  Timestamp     Src_IPaddr     srcprt  Dst_IPaddr     dstprt typ  proto      detail
 11:09:25.241  10.0.0.101      49506  50.205.57.38      123  UDP    NTP      (48 bytes)
      0000  0b000000 00000000 00000000 00000000 00000000   ....................
      0014  00000000 e8651e25 3db22d0e 00000000 00000000   ....he.%=2-.........
      0028  00000000 00000000                              ........
 11:09:25.279  50.205.57.38      123  10.0.0.101      49506  UDP    NTP      (48 bytes)
      0000  0c0106e7 00000000 00000000 47505300 e8651e25   ...g........GPS.he.%
      0014  00000000 00000000 00000000 e8651e25 423bb099   ............he.%B;0.
      0028  e8651e25 423c015d                              he.%B<.]

bruce_dev />  ​  ​

You can use the HELP FILTER command to get detail on the packet filtering. One note about the HELP detail (if it hasn't yet been updated) is that you might need to place double-quotes around your filter on the command line. The AND and OR logical operator characters now have meaning in piping and combining multiple commands on the command line. The quoting keeps the OS from getting confused.

[Carsten Kurz]

Great feature!

[Bruce Cloutier]

Yeah the support guys here really like the NETSTAT built-in sniffer thing. It helps to prove that the JNIOR is doing the right thing when, perhaps, the projector isn't. Or, to show that the media server isn't sending the right thing to the JNIOR. You know, like with all the questions about how to send CR and LF. Stuff of that nature.

Um, you can set the IpConfig/Promiscuous registry key to enabled (or true or any of those). And if you use a hub as opposed to a switch the JNIOR can see traffic between other devices on that segment. In that case you might watch the media server talk directly to the projector. Try to avoid dumping jumbo frames.

We keep hubs in here for that reason when we are using Wireshark to diagnose issues. I would imagine that the JNIOR can play in that arena too. If you try that let me know what you think.

We try to aid in diagnostics. So this goes along with IOLOG both for digital I/O and AUX port serial.

[Bruce Cloutier]

Here is something that you can now do with JANOS v2.4 given that I finally took the time to mimic a real command line.

bruce_dev /> reg -x * | egrep =\\s*$
  Beacon/Announce =
  Beacon/AutoAnnounce =
  Beacon/Enabled =
  COMSerial/Baudrate =
  COMSerial/BootDialog =
  COMSerial/Databits =
  Websocket/Files =
     .
     .
     .
  Zip/Depth =
  Zip/Window =

bruce_dev />  ​
​

In case you are wondering what are these mysterious registry keys? The REG -X option includes the known (documented) registry keys in the listing even when not set. So here I listed ALL of the registry keys and piped that to EGREP to pull out those that are not set. In this case that would be the system keys. So... IpConfig/Promiscuous will be among them.

Um, in REGEX \s matches whitespace. There is a space after the '=' sign. But on the command line you need to escape the '\'.

This works too.

reg -x * | egrep "= $"

Yeah, I wrote the REGEX too. I didn't bother with some of the complex look ahead stuff. Use HELP REGEX for a cheat sheet. This implementation employs a fun little state machine wherein multiple pointers run all trough it until one declares a match. Er, well, I handle both lazy and greedy matching. Fun. Anyway, the REGEX has been available in the JNIOR for quite a while.

[Bruce Cloutier]

Here's another one that comes with JANOS v2.4.

As you know .LOG files are limited to 64KB. Once a log grows to about that size it is aged to a ,BAK copy overwriting any prior .BAK and the .LOG starts anew. This is because the root of the file system enjoys high-speed SRAM which is limited to 2MB. So after a while for the jniorsys.log you have from 64KB to 128KB of log data available between the two files jniorsys.log and jniorsys.log.bak.

It is a bit of a pain then to have to look in two places when scanning the log backwards for some event. Not anymore. With the latest OS release the CAT command accepts more than one file concatenating them in order. Better yet this accepts wildcards where it concatenates in date order. So this command

cat jniorsys.log*

displays the content of the older .BAK file followed by the current .LOG file all in sequence.

Here we see this particular LOG file set and use not only this feature of CAT but piping the output to the new HEAD command to see the oldest log entry.

bruce_dev /> ls jniorsys* -l
total 2
-rw-r--r--   1 root      root       41377 Jul 25 12:46 jniorsys.log
-rw-r--r--   1 root      root       65579 May 23 12:44 jniorsys.log.bak
  1,487.9 KB available

bruce_dev /> cat jniorsys.log* | head 1
05/06/23 16:41:47.327, Attention Flag manually reset

bruce_dev />​

What were the last 8 times the clock synchronized using NTP?

bruce_dev /> cat jniorsys.log* | grep NTP | tail 8
07/21/23 15:37:07.001, Clock synchronized via NTP (-5) stratum:1 36ms
07/21/23 15:57:49.001, Clock synchronized via NTP (-8) stratum:1 36ms
07/21/23 16:09:46.001, Clock synchronized via NTP (-2) stratum:1 39ms
07/21/23 16:24:11.001, Clock synchronized via NTP (-1) stratum:1 39ms
07/21/23 16:26:51.001, Clock synchronized via NTP (-6) stratum:1 37ms
07/21/23 16:32:07.001, Clock synchronized via NTP (-2) stratum:1 38ms
07/24/23 12:05:58.001, Clock synchronized via NTP (-11) stratum:1 36ms
07/25/23 12:45:55.000, Clock synchronized via NTP (+42) stratum:1 38ms

bruce_dev />  ​

Um, my development unit boots a lot given that I run it under the debugger.

HEAD and TAIL are also options to the CAT/TYPE command.

I know. I know. Command line... Eww.

BTW, We currently distribute JBakup.jar which can run in the background compressing and archiving log files into flash. Nice if you want the long term records.