The MD3 will scroll 10 log entries at a time, either up or down in the list.
What you can do to change the sort order (F2 button), that will jump to the other end of the log and change the order in which the log records are shown, oldest at the top or oldest at the bottom.
There is a similar topic on this with some more details here:
For the 200 meters at 250 kbps that was mentioned, and that can be in documents, it could be worth mentioning that this is more of an upper theoretical limit, in practice the design of the individual controllers and the wiring harness will limit it to a lower length.
Solved in version 4.07.14 that is now released
To read DM1 info for a J1939 module in the MD4 menu system, there must be a DM1 channel assigned to the J1939 module.
With the IQAN-G3 modem, you can connect with IQANrun and perform any operation you can do locally with IQANrun.
If the DM1 channel is in a measure group, it will be seen there, with the value indicating number of faults.
And the IQANrun system overview will show the J1939 module with channel status of the DM1 if there are active faults.
To see the SPN and FMI:s in this way, you would need to have a channel for each, and have them all in a measure group.
So the answer is no, you cannot view the complete list of unknown SPN:s that the MD4 menu system can show using IQANrun, only that there are active faults.
Yes, with the CRC channel set to the method J1850 CR8 that is possible to select now, the message counter is positioned before the checksum.
To support the CRC you use, it looks like it would also be necessary to add an option for a different CRC.
Thanks for noticing this, the connector numbering for C2 and C3 are swapped. The popup messages for DOUT and the pin number info in expansion modules is affected also, on both XC22 and XC23.
It is perhaps less apparent on the XC22 as this module does not have the center C2 connector.
Perhaps a clarification might be good here, as the purpose described in the post was to connect external switches to the coils, one must not forget the series diode that prevents reverse feed of the high-side driver when the external switch is driving the coil.
For the MD4 bluescreen occuring at startup, version 4.07.12 solves a problem triggered by the application changing backlight a certain time during startup
I checked the case history, and got reminded that there were some problems with send method on request that were resolved in version 3.15, but I am not sure if that could have been the issue you saw back then.
This is how IQAN handles the request PGN 59904 now:
In the request PGN, the DA may be either that of the master module, or broadcast (255).
The SA of the request PGN must match the source address property on the J1939 module that the JFOUT with the send method on request is located on, for the sending of the JFOUT to be triggered.
If there is a request PGN directed the IQAN master from a different source, there will be a response, but the response is a NACK in PGN 59392.
Below is an example of how the application attached to the previous post (that expects the request from SA 40) would respond if the request came from another SA, in this case 128:
That is correct, for these HS+LS combined outputs where the internal diodes are not disconnected, there is no need to add diodes externally to protect the power drivers.
But as long as you are not using the output as COUT, it will be ok to have an additional diode. The external diode messes with the current measurement, but that is no problem as the PWM HS+LS does not use that current measurement circuit.
Customer support service by UserEcho