Posts by PA3FYM

    Bitte die Geschichte hier lesen, bevor die Satelliet lanziert wuerde, haette ich die Frage schon gestellt:

    Sehe hier. Also DER (DIE? <-- Deutsch is nicht meine Muttersprache) Frequenz is die Ausgangsfrequenz.


    So 'QSL-maBig' soll es die Empfangsfrequenz (10489.xxx) sein (?)

    Clear explanation, but then the term 'DATV' , 'TV' , 'ATV' needs to be replaced with 'DVB-S2' (to name a suggestion). In the professional world (like SNG (satellite news gathering) several audio channels (digital, VoIP) are normal e.g. to have communication with the studio control room or camera men.

    DB2OS Everything is possible but your own WB tpx operating rules speak explicitly about 'TV' (DATV, DVB-S2 + bandplan etc). TV has a visual component, i.e. its intention is to transmit pictures/movies etc where sound and/or data component are 'by-catches'. If we leave that perception all (WB) experiments -regardless of their mode of transmission- are 'allowed' on the WB tpx.

    No, don't think they count for 13cm -sec- DXCC ranking as they are not single band QSO's via tropo, or e.g. EME. They (may) count for 'satellite DXCC' (provided it are real 2-way contacts and one party does not use a WebSDR <-- which I cannot enforce b.t.w.). With other satellites it's also Fin is not Fout (e.g. 435 MHz in, 145 MHz out).

    --- white paper --- / --- proposal ---


    Yesterday I made some attempts to upload my QO-100 ADIF log to ClubLog. I followed the recommendations from here (<SAT_NAME:6>QO-100 <PROP_MODE:3>SAT <BAND:4>13CM etc), changed the RX frequencies in 10489.xxx. The log was accepted and processed. However, it was classified as 70cm log (because I use 432 MHz as simplex/transceive IF). After some digging it appeared that every ADIF log entry had a <BAND:4>70CM field.


    Naively as I normally am (NOT ; -) I changed all the RX/TX fields with 3CM --heeding the convention postulated here as an answer to my question concerning 'What is THE frequency?' (I asked this question ~1 month before the satellite was launched because I envisaged difficulties)--- I could upload the log, but it was NOT processed. Apparently ClubLog's perspective is there is no life above 13cm ; -)


    Changing all band fields to <BAND:4>13CM resulted in acceptance and processing of my log. Fine! one can say. But I feel very uncomfortable as I am now (highly) ranked in a world wide 13cm league for which the seemingly underlying philosophy is I made 2-way QSO's on a single band (as is the case with all other bands). In my case this is not true. So, the recommendations given on this forum, to have a QO-100 log accepted, are a 'work around' (or loop hole) to use (QSL / OQRS etc) facilities of ClubLog for QO-100.


    My proposal is the following (and I am willing to pick up the glove to try to seduce/convince ClubLog):


    1. add bands >13cm to the ClubLog database (I reckon EME'ers will agree ; -)

    2. in the special case of QO-100 add a separate category (or 'band') 'QO-100' where ADIF FREQ can be anything, and FREQ_RX field is 10489.xxx Everyone knows/will know that 10489 is allocated to the IARU SAT coordination, so it'll not be mixed up with terrestrial work or EME.

    3. because of 2) or <BAND:3>3CM is 'THE frequency' or <BAND:6>QO-100 to let your uploaded log fall into the proper ClubLog category.


    What say?

    Understood, perfect. Note that perhaps using DEMA (double exponential moving average) may not be 'scientifically correct' (that algorithm has advantages and disadvantages) but it at least gives some additional discipline : -)

    SV1BDS OK, the 'punishment' has to be real hard in conjunction with your airconditioner. When the airconditioner keeps running, or is off, the system behaves nominal? I ask this because now TC is increased very quickly in the beginning, which may result in loosing lock before the OCXO is 'settled' (at least, I experienced that, that's why I checked mod TC.)


    Thanks for the addition, I'll try to work that out in some general conditions, perhaps an extra menu-item to deal with discontinuities like your airconditioner ; -)

    min TC = 16, max TC = 1024

    Yeah, that could also be an idea, to let the TC decrease as a function of the DEMA and/or a more 'sadistic' approach, i.e. 'punish' harder than rewarding. They are now equivalent (>>4) , perhaps the punish part must be twice the reward (from >>4 to >>3)


    DEMA value was chosen arbitrarily , although somewhat based on monitoring its value and my ns-offsets with my contraption.


    Room for improvement, so if you want to experiment with it, I would greatly appreciate that. After all, it's your airconditioner ;; -)

    Well, that reasoning applies after you have a certain magnitude of the transponder noise.


    When the tpx noise was around 10 dB more (the first few months) the perceived SNR (with the same dish) was higher.


    Imagine the following experiment:


    Suppose you have the tpx noise floor with +10 dB over your system noise and the tpx relays a signal which is 3 dB above the tpx noise floor.


    Then the overall tpx gain/power (whatever) is reduced with 10 dB so that the tpx noise is equal to your system noise (and the 3 dB signal is still being relayed).


    Having the tpx equally strong as your system noise, the whole noise figure (or SNR) degrades by 3 dB (now you have twice as much noise, because the two noise sources are independent, they can be added stochastically) which also makes the 3 dB signal vanish (into the noise).

    SV1BDS I saw the logs. Again interesting . . . The 'more frequent sampling' trick works to some extend but apparently your airconditioner does 'something' to which the system can't react fast enough. I also see from your time constant (TC) values that your system is (intrinsically) stable. I never had such large TC's with my setup. What is also interesting, is that your DAC value remains ultra stable, also when TC is lowered.

    Perhaps you can experiment with the temperature compensation factor (parameter 'c' in the terminal), it's zero (0) by default. Perhaps try to give it a value ? Point is, that with long TC times, it takes a long time before you notice something, so experimening with temp coeff values will be tedious . . .


    I am now in the process rewriting some of the c0de because the TIC software will be enriched with an NMEA parser to display locator and QO-100 AZ and EL angles on a LCD display. Just I leave it here for now and come back later on the 'airconditioner' issue ; -)