Aximmetry not reliably parsing LONET2 Data

 

As the title says, Aximmetry has not been reliably receiving/parsing data from our Indiemark 2 lens encoder. We have gotten the encoder to work with both the Aximmetry composer and basic calibrator in the past, however, the reliability of whether it would connect has always been inconsistent even with no known changes made to anything.

Using the basic calibrator, we have previously achieved a full focus calibration with different camera lenses. In composer, we have recorded a full shoot with focus accurately affecting a cooked unreal scene using a camera tracking node linked to the LEDWallCam compound.

We have tried all known troubleshooting steps to identify the root cause of this issue but cannot find any solution to use the encoder as intended.

Just today, we managed to successfully receive incoming LONET packets using the UDP Receiver node, which displayed as raw JSON text. This confirms the packets are being received by Aximmetry but, we are theorizing that JSON or structured data from LONET does not parse correctly in Aximmetry’s default processing pipeline. 


What has been verified:

Network Configs:

- LONET 2.7.2 correctly broadcasts data on ports 60609 and 60608 to 127.0.0.1 ; using multicast 236.12.12.12

- All Aximmetry settings pertaining to the encoder in both composer and basic calibrator, were triple checked, including proper mapping and config


Network Debugging Steps:


- Verified no port conflicts (60608, 60609)

- Checked multicast group subscription (236.12.12.12 & 255.255.255.255)

- Captured broadcasted UDP packets from LONET using Wireshark

Confirmed port status of Aximmetry and LONET with PortQry (listening/not listening)

- Confirmed firewall wasn't blocking traffic


Software:

- Aximmetry Composer & Basic Calibrator 2024.3.0/2025.1.0BETA

-LONET Software v. 2.6.2 | 2.7 | 3Beta


Additional:

- localhost and ethernet adapter were both tested in combination between lonet and axim


   Haptix

 
Profile Image
Eifert@Aximmetry
  -  

Hi,

I recommend checking it with the Aximmetry Camera Tracking module. This module is used across Aximmetry, including in the Basic Calibrator. You can find our documentation on debugging with it here: https://aximmetry.com/learn/virtual-production-workflow/tracking/how-to-set-up-tracking-systems-in-aximmetry/#checking-the-tracking-data-flow

Since version 2025.1.0 BETA, the Camera Tracking module can also display raw packets, giving you a clearer idea of where issues might arise:

If you're experiencing issues with the Camera Tracking module too, could you please provide more details? Specifically:

  • Are you receiving data in the Zoom Raw Packet, Zoom Sensor, or Focus Sensor pins?
  • If yes, do you see data in the Focus Distance or Zoom Factor when using your calibration profile in the Camera Tracking module?
  • If you are not receiving data, does this occur consistently or intermittently?
  • Do you notice any messages in the Aximmetry log related to this issue?

Please let me know so we can further investigate.

Warmest regards,

 
Profile Image
Haptix
  -  

Hello thank you for your reply,

To simply answer your questions:

- We are not receiving data in the Zoom Raw Packet, Zoom Sensor, or Focus Sensor pins

- Not receiving data occurs consistently

- The only messages related to the encoder in the log and message panel are "no input"Aximmetry not reliably parsing LONET2 DataAximmetry not reliably parsing LONET2 DataAximmetry not reliably parsing LONET2 DataAximmetry not reliably parsing LONET2 Data


The testing we have just done was using the 2025 beta version and LONET 2.7

Also attached is a screenshot showing the udp receiver module displaying raw data, also in the 2025 beta version.



 
Profile Image
Eifert@Aximmetry
  -  

Hi,

I think the issue lies in the Camera name provided in the Manage Devices section.
The UDP packet displays the cameraName as "RED Komodo".
Aximmetry not reliably parsing LONET2 Data

If I am right, you should set that same name in Manage Devices for the Camera:

Note, that Lonet can send multiple value types from various cameras, and it uses names to differentiate between them.

Warmest regards,

;