Load data

[ClaudMor]

Hello,

I'm absolutely new to Yamcs. From the notes it is clear how to load the SCOS2K tables. But how does one load the actual ccsds data?

Thanks in advance

[ClaudMor]

Yes, the vc1 increases. events: a "corrupted frame" from source:GenericPacketPreprocessor appears once in a while. How do i disable the crc at packet level? Packet-viewer now works (it shows packets as they arrive. I forgot to set the stream to tm_realtime), even though it throws a lot of

java.lang.ArrayIndexOutOfBoundsException when extracting from the buffer (parameter specifications follow)

I installed the client and the server via rpm

Any idea on this:

2.Moreover, the "latest value" of parameters does not update (or how may i check if any parameter actually does without having to click on each of them in the we interface? they're too many of them)

thank you very much

[xpromache]

Yes, the vc1 increases. events: a "corrupted frame" from source:GenericPacketPreprocessor appears once in a while. How do i disable the crc at packet level?

remove or comment out the errorDetection: under the packetPreprocessorArgs.

Packet-viewer now works (it shows packets as they arrive. I forgot to set the stream to tm_realtime), even though it throws a lot of

java.lang.ArrayIndexOutOfBoundsException when extracting from the buffer (parameter specifications follow)
This means that it tries to extract parameters that are beyond the packet - so  maybe the packets it extracts are not correct. You should be able to see the binary of the packets in the packet viewer.

Any idea on this:

> 2.Moreover, the "latest value" of parameters does not update (or how may i check if any parameter actually does without having to click on each of them in the we interface? they're too many of them)

We had a websocket method subscribeAll but I see that it is not working in the python client so the only way would be to write yourself a websocket client. But the packet viewer should already give an indication on which parameters would be extracted from the packets.

[ClaudMor]

Ok thanks.

So i see on the packet-viewers a lot of parameters with the respective values, but i can't see them via the webSocket.

what i do is creating a webSocket via:

var socket = new WebSocket(`ws://localhost:8090/_websocket/simulator`);  

and then do:

      socket.send(JSON.stringify([1,1,789,
                {
                  parameter: 'subscribeAll'

     }]));

I'm not getting anything out of it (no response from the server).

Is it correct? The documentation reports "unsubscribeAll" but not "subscribeAll".

[xpromache]

It looks like the subcribeAll was broken for some time, probably that's why it was removed from the documentation. We had planned for a long time to improve multiparameter subscription (for example to be able to subscribe to all from a namespace) but never got the time to do it.

I made some sort of fix in the master of yamcs of github, you can give it a try if you want (you need to recompile yamcs).

I tested it with this python script:

import websocket
ws = websocket.WebSocket()
wsaddr = "ws://localhost:8090/_websocket/simulator"
print "Connecting to "+wsaddr + "...",
ws.connect(wsaddr)
print "connected"

print " subscribing to parameters...",

ws.send('[1,1,3, {"parameter": "subscribeAll"} ]')

print "subscribed"
while True:
    result =  ws.recv()
    print "Received '%s'" % result

[ClaudMor]

Ok, we'll try it and let you know.

i noticed that when removing the simulatorCommader section from yamcs.simulator.yaml , the tm_realtime stream results "unavailable" in the web interface, although it is declared in the stream section. I think it should be active if we want to let processors extract data from it.

How to enable it?

thank you

EDIT: does the errorCorrection field in the configuration of the UdptmFrameLink refer to FECW?

EDIT2: maybe i answered myself to the first question: it is the tm_realtime datalink to be "unavailable", not the stream, which infact is accessible by the packet-viewer. I think the problem now is that the TM archive is empty although the in_count of the UDP_FRAME_IN increases.

[xpromache]

how do you see the TM archive is empty?

One problem which I expect you will have is the timestamp inside packets. Not sure what sort of packets do you have PUS? do they have a timestamp?

If the timestamp is wrong (very likely) the data will be archived with some odd timestamp (very much in the future or in the past). I have to put an option in the preprocessor to just use the current time instead of the time extracted from the packet.

[ClaudMor]

Hello,

Yes, we have pus, which means that timestamp is in CUC format (6 bytes) and the 14-bits Sequence Count is preceeded by 2 bits of sequence flag.

You are right, we see impossible dates.

how do you see the TM archive is empty?

In the web interface, i see no bar forming while i the UDP_FRAME_IN counter increases. Anyway it should be said that the client service "archive-browser" actually sees the packets. In "yamcs-monitor", the processor "Parameter Archive" is not present, although its configuration is identical to the one on github.

Thank you

[xpromache]

Maybe you should try the PUS packet preprocessor: https://www.yamcs.org/yamcs/javadoc/org/yamcs/tctm/pus/PusPacketPreprocessor.html

hopefully this one will get the time right.

On Wed, Jun 12, 2019 at 9:20 AM claudio20497 notifications@github.com wrote:

Hello,

Yes, we have pus, which means that timestamp is in CUC format (6 bytes) and the 14-bits Sequence Count is preceeded by 2 bits of sequence flag.

You are right, we see impossible dates.

how do you see the TM archive is empty?

In the web interface, i see no bar forming while i the UDP_FRAME_IN counter increases. Anyway it should be said that the client service "archive-browser" actually sees the packets. In "yamcs-monitor", the processor "Parameter Archive" is not present, although its configuration is identical to the one on github https://github.com/yamcs/yamcs/blob/master/yamcs-simulation/etc/processor.yaml .

Thank you

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/yamcs/yamcs-scos2k/issues/1?email_source=notifications&email_token=AAG6ARYKTKIITGPX4B3D4WDP2CPU7A5CNFSM4HP2SDXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXPPTEY#issuecomment-501152147, or mute the thread https://github.com/notifications/unsubscribe-auth/AAG6AR2GPBLEF235IFVUKZTP2CPU7ANCNFSM4HP2SDXA .

[ClaudMor]

hello,

I see that although we have CCSDS 133.0-B-2 data, the PusPacketPreprocessor (which is CCSDS 133.0-B-1 compliant), fits our packet header well (i don't know if there will be other problems later, maybe you do?). It unfortunately doesn't seem to get the time right, but it could be a problem related to how i configure it. So by reading its implementation (expecially the configureTimedecoder method), i came up with this configuration:

packetPreprocessorClassName: org.yamcs.tctm.pus.PusPacketPreprocessor
packetPreprocessorArgs:
    timeEncoding:     
        type: "CUC"
        pktTimeOffset:   #see later
    implicitPField:  #see later
    errorDetection: #last two bytes are used for the error detection
        type: "CRC-16-CCIIT"  #"16-SUM"   #"CRC-16-CCIIT" 

which doesn't crash, but doesn't get the time right either. So i don't know if there are other configuration fields available. Maybe these questions could solve it:

1. Where is the pktTimeOffset calculated from?
2. What is implicitPField and how is it evaluated?
3. Is "stripEncapsulationHeader: true" needed for this preProcessor?

do you have any update about this:

EDIT: does the errorCorrection field in the configuration of the UdptmFrameLink refer to FECW?

EDIT2: If from the web interface i navigate to TM archive, i see no packets (even if i use the "jump to" button and paste the rectime or the gentime of the incoming packets). Reading the code, i found that in order to activate the archives maybe one has to put the following configurations inside yamcs.simulator.yaml :

  - class: org.yamcs.ProcessorCreatorService
    args: 
      name: "Archive"
      type: "Archive"
      spec: '{ "utcStart":"1969-01-01T00:00:00.000Z", "utcStop":"2019-12-31T23:59:59.999Z", "endAction":1, "reverse":false }'

(same thing for ParameterArchive and ArchiveRetrieval). Is it correct ? (it gives no errors, and it opens and closes a stream at server startup)

Now i see all processors in the yamcs-monitor , but they receive no packets. Only the realtime processor does. We may begin by making the TM archive work.

EDIT3: I was wrong: it is true that in the TM archive i see non bar filling, but if i select a range on the time axis which i know the data to be distributed in and click download, then i get a file with our telemetry. It doesn't happen if i select a range in which there is no data. Same behaviour for the archive-browser. Anyway i don't really know why it behaves this way, so if you would like to explain what configuration should one use to get the archive to work properly it would be great. Another issue is that although in your plugin there is a configuration "epoch", which from the source code i think it could be set to "UNIX", "TAI", "J2000", "GPS", even if i switch from "UNIX" to any other the packets gentime and rectime don't change. It think this is due to the fact that the PusPacketPreprocessor has a CuCTimeDecoder in it which doesn't seem to look at the scos-mib configuration. Or maybe is it because another reason?

As always, thank you.

[xpromache]

Sorry for not answering earlier, I was out for a medical intervention, coming slowly back online...

As far as I understand the pktTimeOffset sets the offset in the packet where the time is read from. The implicitPField determines the format of the CUC time in case the format is predefined. If you see this standard: https://public.ccsds.org/Pubs/301x0b4e1.pdf Chapter 3.1.1 you can have implicit or explicit P-field. Implicit means that is defined in the config file and not in the packet. Explicit means that it is part of each packet.

stripEncapsulationHeader is not used for that pre-processor (it's only used for virtual channels containing CCSDS encapsulation packets (that is different sort of packets than PUS))

Maybe it's easier if you tell me the format of your packets and they I can try to figure out a suitable configuration.