Comment #1: Wed, 11 Sep 2019, 11:25 (GMT+1, DST)

Quote

Yes the connectors definitely do have an effect, especially the cheaper ones. Typically the reflected signal changes by a few percent when adding an adapter.

Comment #2: Wed, 11 Sep 2019, 11:20 (GMT+1, DST)

Quote

It is real but it's coincidental. Due to constructive and destructive interference it is possible that at some point, all reflections cancel each other out, and the total reflected signal will be almost zero. But since this is at -30dB we're talking about a difference of 0.1%, which is not significant. Basically it's noise, it will be different for every unit due to manufacturing tolerances.

Comment #3: Wed, 11 Sep 2019, 10:52 (GMT+1, DST)

Quote

Are you sure there are no other differences between the files? crf=0 should definitely look better.

keyint is expressed in frames, not seconds. keyint=1 means every frame is a keyframe. If you want a keyframe every second at, say, 30 fps, you would use keyint=30. Note that the actual keyframes may not be exactly 30 frames apart though, since the encoder tries to align keyframes with scene changes whenever possible. So you can't really rely on this. The default keyframe interval is something like 250 frames I believe, which isn't very good for editing.

Comment #4: Fri, 30 Aug 2019, 18:54 (GMT+1, DST)

Quote

I imagine any lossy materials used in the connector or coax that change the Q may cause these to be a little broader.

And 5.8GHz do you actually see the impedance bump from the connectors?

Have you ever popped a few adapters inline to see how it changes?

Comment #5: Fri, 30 Aug 2019, 18:40 (GMT+1, DST)

Quote

Wish I had some nice test equipment for this stuff.
I have an old thing that only goes up to 1GHz.

Have you ever pulled off the plastic radomes just to see if it changes much?
I will sometimes pop a radome itself in the microwave for a few seconds.
If it gets warm or hot it's not good material for 2.4Ghz+

Comment #6: Fri, 30 Aug 2019, 18:33 (GMT+1, DST)

Quote

I'm curious about the total dropout below -30 on the one antenna.
Is that real?
And why would the other antenna not have a similar dropout?

Comment #7: Fri, 30 Aug 2019, 18:27 (GMT+1, DST)

Quote

And all of this said and tested.
At the end of the day it works very poorly.
In all of my tests comparing this antenna to a simple dipole the dipole has always
captured much more signal at a distance over the same test range.

Comment #8: Sun, 28 Jul 2019, 20:05 (GMT+1, DST)

Quote

thanks for clarifying.

actually, crf value was a typo, was 0 already.

zooming in and comparing the 2 pngs (lossless crf:0 vs lossy crf:20), the latter is definitely the winner - though it makes no sense to me?

regarding the keyinterval, what would be the drawback of leaving this at a default value of 1? this way, accurate cuts of at least 1sec intervals would be possible, after all.

Last modified: Sun, 28 Jul 2019, 20:06 (GMT+1, DST)

Comment #9: Sun, 28 Jul 2019, 17:51 (GMT+1, DST)

Quote

What you describe:

codec:other, libx264, bitrate:0, preset=veryfast,crf=15,keyint=1

... isn't lossless. If you want actual lossless, try:

codec:other, libx264, bitrate:0, preset=veryfast,crf=0,keyint=1,pixelformat=yuv444

or if your editing software supports H.264 RGB:

codec:other, libx264rgb, bitrate:0, preset=veryfast,crf=0,keyint=1

The option crf=0 is what makes it lossless. keyint=1 turns every frame into a keyframe to make editing easier.

Last modified: Sun, 28 Jul 2019, 17:52 (GMT+1, DST)

Comment #10: Wed, 24 Jul 2019, 13:13 (GMT+1, DST)

Quote

hi maarten,

there you go, i've only ever used avidemux with my h.264 screencasts (ssr default settings + crf 20) and cutting (without errors) is only possible on i-frame base in this mode. i wished accurate cutting was also possible with these final encodes.

now, i noticed something strange when recording losslessly (codec:other, libx264, bitrate:0, preset=veryfast,crf=15,keyint=1). i took stills of a scene from a lossless screencast vs lossy sc (h.264, crf 20, preset veryfast) and i could clearly spot artefacts in the lossless picture. the lossy one looks far superior. how is that possible after all?

apart from crf, bitrate and the keyinterval, the settings should be identical, i guess.

Comment #11: Tue, 23 Jul 2019, 2:38 (GMT+1, DST)

Quote

H.264 should definitely allow accurate cuts, if it doesn't its a limitation of the editing software, not the codec. In any case, H.264 lossless should work about as well for editing as mjpeg if you add the keyint=1 option. There are some other lossless alternatives (like huffyuv) but they don't compress as well as H.264.

By the way, you may want to use libx264rgb instead of libx264, or use libx264 with pixelformat=yuv444.

Comment #12: Tue, 23 Jul 2019, 2:29 (GMT+1, DST)

Quote

Currently I'm not working on this, but I will keep it in mind for the future. It should be possible to make a size-optimized design at the expense of some of the other specs.

Comment #13: Sun, 14 Jul 2019, 10:44 (GMT+1, DST)

Quote

just a quick question: is lossless mjpg recording possible with ssr? if not, which lossless codec to choose from in order to do precise cuts with avidemux later on? h.264 (lossless) unfortunately does not allow accurate cuts.

Comment #14: Thu, 11 Jul 2019, 11:54 (GMT+1, DST)

Quote

I have put pagoda and a triple feed antennae on my receiver, and subjectively - ie amount of breakup and range - when compared to other antennae (I do not have the necessary test equipment) they really do seem to work very well indeed.

They are impressive designs.

I would like to use a pagoda on the craft, but as it is a small quad, weight becomes a big issue. I notice that the pagoda is designed specifically for RG402. RG402 is quite heavy, and so are SMA connectors. RG178 is much lighter, and so are MMCX connectors.

I did find this - https://uk.banggood.com/5_8GHz-2_2dBi-RHCP-Mini-Pagoda-Antenna-MMCX-Connector-for-FPV-RC-Airplane-p-1341375.html?gmcCountry=GB&currency=GBP&createTmp=1&utm_source=googleshopping&utm_medium=cpc_bgcs&utm_content=garman&utm_campaign=ssc-gbg-all&ad_id=332556156911&gclid=EAIaIQobChMIopjXlMis4wIVqrvtCh14bw7pEAQYDyABEgKLaPD_BwE&ID=224&cur_warehouse=CN - on the Banggood website which is pretty light (2-3g all in), but having read the comments above and your replies, I doubt it is likely to work that well. (1) It isn't RG402 - difficult to be sure but more likely RG178 or similar, and (2) the bottom PCB is missing.

I assume they have just modified your design, unclear whether it has been tested.

I wondered if there was any likelihood of a pagoda design based round RG178 (or RG316 at a pinch) being produced? I accept your point in the comments that flexible coax is not ideal in terms of keeping everything in place (so would need styrofoam spacering), and of course, RG178 is much higher loss at 6GHz. However flexible coax is what is needed here from a mechanical mounting perspective.

Also, on the other hand, tiny quads don't tend to fly so far, so maybe some inefficiency is less of an issue.

I would be interested to know if anything like this is on the cards?

Comment #15: Wed, 3 Jul 2019, 16:24 (GMT+1, DST)

Quote

I panelized some antennas. https://github.com/japhillips87/pagodas

The first gerber is the Pagoda 2 version. It has 3 RHCP and 3 LHCP on one PCB. The second gerber is the Pagoda 2B version. It also has 3 RHCP and 3 LHCP. I have not ordered these, but I uploaded it to JLCPCB and it doesn't have any errors.

Comment #16: Mon, 10 Jun 2019, 21:53 (GMT+1, DST)

Quote

Theoretically possible but very tricky - at 5.8 GHz the value would end up being extremely small (in the range of 0.1 pF). The parasitics of the pads and solder would be higher than the actual capacitance value.

Comment #17: Mon, 10 Jun 2019, 21:50 (GMT+1, DST)

Quote

Http Dll 2 doesn't compress the data unless you do it manually. Are you sure that the buffer is actually compressed? Have you taken care of the length prefix of the message properly?

Comment #18: Mon, 10 Jun 2019, 12:24 (GMT+1, DST)

Quote

Perhaps a stupid idea: Wouldn´t it be possible to add a trimmer capacitor in the design to do some frequency tuning and compensate tolerances during assembly?

Comment #19: Tue, 28 May 2019, 2:40 (GMT+1, DST)

Quote

Hello, I'm trying to write a custom server for a client that uses HTTP DLL 2 to send data to a socket.

I would like to code the server in nodejs (or perhaps even python), but the data sent to the socket cannot be simply uncompressed using zlib.inflate (it says there's a bad header check)

Do you know how you would be able to make a receiver (in another language) that can read HTTP DLL 2 socket messages?

Comment #20: Mon, 13 May 2019, 11:49 (GMT+1, DST)

Quote

ok, so to sum it up, recording at a given framerate (say 60) in ssr will be maintained, even after trimming with avidemux, though probably reported differently, because of changes in depending libraries?

good to know ;)

Comment #21: Sun, 12 May 2019, 18:16 (GMT+1, DST)

Quote

The length of the coax is not very important, but the diameter is. RG178 is thinner than RG402 and this will affect the performance.

Comment #22: Sun, 12 May 2019, 18:15 (GMT+1, DST)

Quote

mkv, 60fps, h.264 + crf 20 + veryfast preset + uncompressed audio

Since your screen runs at 60 Hz, recording at anything other than 60 fps will likely just results in some frames being duplicated or dropped. So it makes sense to record at the same frame rate as your screen. So unless you can change your screen to 50 Hz I would stick to 60 fps. The exception would be if you disable vsync in your compositor as well as the application being recorded, and configure the application to run at a much higher frame rate than your recording frame rate. But this will likely cause tearing.

Whether disabling the compositor will introduce screen tearing depends on your GPU driver as well as the application being recorded. The only way to eliminate screen tearing completely is to use OpenGL recording.

This is a common feature request, but it hasn't been implemented yet.

Comment #23: Sun, 12 May 2019, 17:59 (GMT+1, DST)

Quote

This is because the underlying libraries (ffmpeg) have changed. It also depends on the choice of codecs and file format. It shouldn't affect the frame rate of the actual video though, since each frame has its own timestamp.

Comment #24: Wed, 8 May 2019, 11:47 (GMT+1, DST)

Quote

hello there,

i am not sure where to address this in first place, perhaps you can help here already?

recently, i found out that the reported framerate of my 60.000 ssr mkv (h.264) recordings are interpreted differently, depending on the software in use.

while mediainfo shows a framerate of 60.119 fps, avidemux' file properties states a value of 62.500 fps, which is on par with shotcut on the other hand.

there is old ssr mkv recordings of mine, which report a uniform framerate of 60.000 fps in every software, also after trimming/exporting with avidemux, so i wonder what has changed after all?

Comment #25: Wed, 1 May 2019, 18:05 (GMT+1, DST)

Quote

Hello. 9 cm must coax be? Can I shorten it and solder the RG178 for a direct connection via a U. FL / IPX connector on a quadcopter?
Example: https://aliexpress.com/item/Foxeer-Pro-5-8-2dbi-RHCP-FPV/32846545534.html

Comment #26: Tue, 30 Apr 2019, 14:05 (GMT+1, DST)

Quote

The transmission line simulator is a really nice tool!
The only one that's free and capable of calculating coplanar differential waveguides.
I hope that it will be possible someday to add entries to the substrate material within the GUI.

Last modified: Tue, 30 Apr 2019, 14:08 (GMT+1, DST)

Comment #27: Sat, 27 Apr 2019, 19:40 (GMT+1, DST)

Quote

Hi,

I am trying to record a presentation that I will lose access to in a month. I did this with one and it works great, but I have to set it up when I leave because my computer records outside noises, too.

My question: is there a way to set a recording time so it will cut up when the presentation is over? I know how long it is, but sometimes I have to leave for longer, and it would be nice if it would cut off when the presentation was over instead of recording for 6 hours (these presentations are about 3 hours long.

Just wondered if it was possible, or if there is a way to make it possible...

Thanks so much!
Tina

Comment #28: Fri, 26 Apr 2019, 15:16 (GMT+1, DST)

Quote

hi maarten,

well, here is what i try to achieve:

record as .mkv in the 'best' possible way already (in regards to my hardware), in order to avoid an additional long video transcoding process - but, at the same time, still have the option to burn a pal dvd later on (with minimal quality loss during transcoding).

so i went for these options which work very well on my machine

mkv, 60fps, h.264 + crf 20 + veryfast preset + uncompressed audio

the setting i am unsure about - which optimal mkv framerate to go with initially (for best possible pal dvd conversion)? 50fps or 60fps > 25fps?

p.s.: i can barely notice a benefit in framerates while recording with the compositor enabled / disabled under kde plasma?

on the contrary, i even read an advice to not disable it (except for old hardware) so to avoid screen tearing effects! is that true?

Last modified: Fri, 26 Apr 2019, 15:17 (GMT+1, DST)

Comment #29: Mon, 22 Apr 2019, 12:29 (GMT+1, DST)

Quote

Please read the earlier comments.

Comment #30: Mon, 8 Apr 2019, 9:55 (GMT+1, DST)

Quote

When a 2.4ghz Pagoda? *.*