getting tm eng value with vcid

37 views
Skip to first unread message

Nao

unread,
Aug 3, 2025, 4:19:43 PMAug 3
to yamcs
Dear all,
We want to have telemetry engineering value with vcid value.

In CCSDS TM architecture, the association between tm eng value to vcid value has no meaning. But for test purpose in our case, the association is useful. Since each raw value has single association to tm packet and tm packet has single association to tm frame,, tm engineering value with raw value has single association to vcid value of the frame. We want record this association.

Here's my idea. 
  • Make a new class which extends TmPacket and implement setVcid() and getVcid(). Let the extended class named TmPacket2. 
  • Yamcs, packetPreprocessorClassName can be specified for each virtual channel in Telemetry Frame Processing, specify different PacketProcessor for each vcId. Let the class name named MyPacketProcessor.
  • In MyPacketProcessor.process(), 
    • create TlmPacket2
    • copy TlmPacket passed as method argument,
    • set vcid value in some way.
    • return the TmPacket2 instance.
Then at any point after MyPacketProcessor vcid value is accessible with TmPacket instance with type cast.

Let me know comments about whether this works or not.

Thanks in advance.

Nicolae Mihalache

unread,
Aug 6, 2025, 3:33:44 AMAug 6
to yamcs
And what do you do with the TmPacket2? 

The TmPacket objects are short lived, the data will be transformed to a tuple and sent on the tm stream from where it is being picked by the XtceTmRecorder or by the processor.

Nao

unread,
Aug 6, 2025, 8:28:18 AMAug 6
to yamcs
Thanks for reply.

We want to store vcid value with each telemetry engineering value. This is the goal in Yamcs. With the telemetry engineering value database with with vcid, we can easily filter stored records and show them on screen or save them in file.

Actually I cannot find clearly which class or method is responsible for the 12 steps in the document of "TM Packet Processing". I believe what we want to do can be realize mostly in these steps.

2025年8月6日水曜日 16:33:44 UTC+9 Nicolae Mihalache:

Nicolae Mihalache

unread,
Aug 6, 2025, 2:04:10 PMAug 6
to ya...@googlegroups.com
I think easiest you can do is to prepend the vcId to be binary packet in the preprocessor. Then you add it to the MDB and it should be extracted together with the other parameters.





--
You received this message because you are subscribed to the Google Groups "yamcs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to yamcs+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/yamcs/5ffaabef-2df2-4eab-b05e-2917bc20434en%40googlegroups.com.

Nao

unread,
Aug 7, 2025, 10:14:37 AMAug 7
to yamcs
Hi.


> to prepend the vcId to be binary packet in the preprocessor.

Is it possible ? My understanding is when TmPacket(long rectime, long gentime, int seqCount, byte[] pkt) is called, pkt does not contain vcid information. The first byte of pkt is packet primary header.

2025年8月7日木曜日 3:04:10 UTC+9 Nicolae Mihalache:

Nicolae Mihalache

unread,
Aug 8, 2025, 6:19:01 AMAug 8
to ya...@googlegroups.com
You are right, we need to get the vcId from somewhere. 
I suggest we add a "int vcId = -1" field to the standard TmPacket which we set by default to -1 meaning it is not set. 

Then in the VcTmPacketHandler we can set it to the VC Id which that class has access to. 

If you want, you can make a pull request for this. You will need to sign the CLA though.

Then you can prepend it to the packet in your own packet post-processor.

In the future:
- we make the vcId and ert (earth reception time) as part of some sort of packet metadata. The post-processors will be able to add more stuff to that metadata. I want the packet name also to be part of it.
- we allow the metadata to be propagated/associated with the parameters in the parameter archive.

Have fun!
nicolae

Nao

unread,
Aug 8, 2025, 9:41:21 PMAug 8
to yamcs
Thank you Nicolae.

We'll try this in our system and possibly make pull request. 

2025年8月8日金曜日 19:19:01 UTC+9 Nicolae Mihalache:
Reply all
Reply to author
Forward
0 new messages