The proposal is to have the LNB and Helix not together but offset from one another, e.g. the helix above the LNB. This will impact TX efficiency because the beam is no longer precisely towards the satellite but hopefully not by too much as the beam at 2.4 GHz is 4 times as wide as it is at 10 GHz.
Posts by G0MJW
-
-
This is a good idea and should work for smaller dishes too. The 2.4 GHz beam will not be correct, there will be an elevation error, but this will not matter very much because the 2.4 GHz beamwidth is relatively wide. It could be several degrees out before it matters. If we assume a 3 degree error with a 1m dish we would lose 3dB on TX. A 3 degree error on a 2.4m dish is much more serious, 10 dB down, but of course the distance to the feed is twice as far, so the angular offset for the same physical offset will be smaller and it will all equalise. Offsets have a real advantage as the focal length is usually longer meaning the feed is farther away from the dish and therefore the relative error less.
-
The only way TX should be able to desense RX is for there to be significant 10/12 GHz energy from harmonics of 2.4 GHz. The 2.4 GHz fundamental will not get through the waveguide - (as long as it is long enough, which it should be). Does the same desense occur with a patch rather than a helix?
-
Perfectly logical and it would work if your signal was a tone. I think it would be very hard to do with SSB but it might be possible. Perhaps sub audible tone on the SSB might help, or even a DC carrier.
Mike
-
(Sorry, wir sind hier im deutschsprachigen Forum)
Entschuldigung, da die automatische Übersetzung von Google jetzt so gut ist, merke ich das nicht immer
-
That makes sense. In English we say "main station address" as shown on the license, but this is not helpful for portable operation or when operating at alternative locations. For remote operation I think it has to be the main address or one in a notice of variation. It is something of a grey area.
Another rule, not mentioned by Peter, is that you must be able to listen on frequencies you transmit on. This is absolutely vital in shared spectrum where the primary user may need to request that you stop. This is of course an old rule really intended for where HF bands shared with other services but as a result, operating the AMSAT DL and Khune transverters which are not capable of receiving where they transmit is not strictly legal in the UK, unless the operator has another 2.4 GHz receiver. I have never heard of this rule being applied. It's much more of a risk with LEOs operating at VHF/UHF. We all recall what happened when a cubesat was placed at the bottom of 144 MHz.
Mike
-
A small reminder for the occasion:
Remote operation of an amateur radio station via QO-100 is only permitted if the station belongs to the operator himself and is operated at his own location. He must have full control of the station at all times and, in particular, be able to switch it off immediately if, for example, faults occur. Special cases of unmanned and automatically working stations require a permit from the operator of the space station, in this case represented by the AMSAT-DL, as well as a special permit from the regulatory authority responsible in the respective country. The operator must comply with international and national legal regulations at all times. The above agreement is agreed in accordance with, among others, AMSAT-DL, AMSAT-UK, QARS and Es'hailSat.
Why is there a requirement for the entire station to "belong" to the operator ? This would technically mean ownership of all the hardware and the site it is located in. As long as the rest of these requirements are met and the operator has responsibility for the operation then there is no legal need to have title-absolute surely? I suspect many stations, remote or otherwise will need to close down if for example they rent their home or the hardware still belongs to the credit card company.
Mike
-
A 40cm dish has 18 dB gain at 2.4 GHz. Another potential portable uplink antenna is a standard loop yagi which would need to be about 1m long. Potentially easier to fit in travel baggage if it splits into smaller lengths. For RX you still need the dish though so a dualband feed might be the best answer.
-
That's why I added a second buffer to the reference board. A simple common emitter transistor amplifier should be sufficient. It's only 25 MHz so no need for GHz capable RF devices. Just build it dead bug style.
-
Ah - I wish people would post this a week before the event and not just before. First time the sun has been out in a month and I am too late. Tomorrow is work again....
-
Well done - it's not easy to get ffmpeg to do when you want because there are so many options and documentation is sparse. The nvidia coder only works with cards that support it, as you found, but I am surprised your PC can do real time H265 encoding without hardware and run obs with a CPU load of 7%. I am just using OBS and nvenc as I have a GTX1060 which has hardware H265 encoding and my CPU load is higher than that. One thing to watch is if you have lots of scenes running in the background you can find a lot of CPU use - e.g. Mulitimedia files that carry on decoding rather than start and stop when activated.
SV8RV has demonstrated you can run full HD in 66ks 8-PSK with 8/9 coding, so you should certainly be able to run it in 125ks QPSK. Have a go. Getting the audio vs video timing right is a usual problem at low bit rates. Increasing the PCR/PTS value helps with the timing. That's what this parameter is for.
Moving on to low symbol rates (125 can not really be considered low any more!) we need to reduce audio to of the order of 8kb/s to have enough bandwidth for reasonable 265 Hvideo at 66ks and below. 66ks QPSK might give you a better link budget, but you may be reduced to 640x360 or lower. I think you can do this with your script by making suitable modifications. It might be worth paramatarising this in a script, so you just tell it the data rate (pluto tells you this) and it works out the rest.
Mike
-
I mean the frequency offset
SO
Codefw_setenv xo_correction 40000000For a 40 MHz reference accurate to within 1 Hz. Put your actual measurement in there. Anything outside 25ppm is ignored. If 1 Hz in 40 MHz is not enough accuracy you probably need to get out more, but you are going to have to fix it in your application.
For a different reference clock, e.g 25MHz to use the same reference as a GPS locked LNB reference
Codefw_setenv ad936x_ext_refclk “<250000000>“ -
Display More
Like the LNB, the Pluto can also be operated with an external 25-MHz clock.
It is not necessary to recompile the firmware.
The applied clock frequency must simply be transferred to the Pluto with the following commands:
fw_setenv ad936x_ext_refclk "<25000000>"
fw_setenv xo_correction 25000000
pluto_reboot reset
This is worth a try.
Yes - I think this is really worth emphasising. You can use an external LO and it does not have to be 40 MHz. I saw someone designed a PCB for external input that does the switching so that the internal TCXO operates unless an external reference is present. This seems an ideal solution.
-
Just to add - I don't see -18dB shoulders but with most people with SNRs arould 10 dB max, these would be well below the noise floor of the transponder.
-
How can we reduce the audio bitrate in OBS below 32kS? Would be interesting for RB-modes.
You could turn it off. Otherwise set it to something like 64kb/s and modify the Pluto ffmpeg script to re-encode down to 8kb/s.
-
You can send the audio and video to ffmpeg running on your PC and then forward the TS as UDP to the Pluto. That TS can contain anything you want. You can also modify the Pluto scripts but they are held in a ramdisk so will not survive a reboot. For a while I was uploading modified scripts each time.
The Radion HD 6450 is a very old card and does not have H265 encoding as far as I am aware. The Nvidia cards like the GTX1050/1060 are a better bet, or the Jetson Nano. Make sure it has H265 hardware encoding supported in OBS.
-
What you need are some profiles and examples to get you started. You also need an H265 encoder, e.g. Nvidia card of little box from China. Email me and I will try to help. OBS is the program to use, with UDP to the Pluto running Evaristes firmware. This can be USB or over Ethernet but if USB it needs to be on the same computer. The BATC Wiki should be easy to follow...maybe we need to work on it.
Mike
-
Display More
Hi Mike,
you can use Sun
to cold sky measurement to get G/T of your Rx system. It is common technique from radio astronomy. It is also used often to measure EME setup. Then you can apply VK3UM EME calculator to get final data. However, when your transponder noise floor is 10 dB, you must have good Rx system with sufficient signal margin to cover a possible link deterioration (heavy rain, snow etc.)
73 & GL
Rasto
If you have ever handled a 2.4m solid Andrew dish, which I expect you have, you will know that pointing it at things is not something to be taken lightly. Heavy and unwieldy doesn't really describe it adequately. So, I have not done the cold sky measurement. I have acquired an azimuth bearing that once I can get mechanical assistance to install I will be able to do this. That will be interesting I think.
Mike
-
It's not QSB, the beacons are not constant amplitude. One is on/off CW and the other is BPSK which, after filtering is no longer constant amplitude either. Otherwise signals are stable - there is scintillation of course as expected.
-
278/5000
I am looking for a NIM type Serit FTS4335V or a compatible NIM for test purposes. The NIM may also be defective. I need the part to create a circuit board (MiniTiouner Pro replica) because of the mechanical dimensions. Possibly only on loan for a few days
The NIM mechanical dimensions are given in the data sheet. That's what I used to design my PCB and they were accurate.
Mike
