Comment #1: Fri, 18 Sep 2020, 22:36 (GMT+1, DST)

Quote

8-channel diversity doesn't make much sense, why would you expect one of those eight antennas to provide a substantially better signal than the others when they are all pointed in the same direction? Or did you mean 8-channel beam steering or MIMO? That would make more sense and should work at least in theory. Just follow the usual rules with regard to patch spacing.

If you just want a more directional version then I recommend the triple feed patch array instead, the hexagonal arrangement produces much better results than a regular grid and it only needs one input feed.

Comment #2: Thu, 17 Sep 2020, 21:34 (GMT+1, DST)

Quote

You see any issues with making a single pcb with 2x8 array of these? This would be for a 8ch diversity
ground station.

Comment #3: Tue, 25 Aug 2020, 16:11 (GMT+1, DST)

Quote

You could be right. I do use ALSA, I'll remember that. I will conduct a test and provide feedback. I'll create a Zoom Meeting on another machine and see what happens on my Linux box when I try to record with SSR. Will provide feeback before the week is out. Thanks for the tip.

Last modified: Tue, 25 Aug 2020, 19:43 (GMT+1, DST)

Comment #4: Sat, 22 Aug 2020, 16:44 (GMT+1, DST)

Quote

I need more information. Can you post a screenshot of your audio settings in both SSR and Zoom?

The most likely cause for this problem is that Zoom and SSR are trying to access your microphone in a way that is not compatible. E.g. you may have configured either Zoom or SSR to open the microphone in exclusive mode with ALSA, which does not work. Or maybe one of the two applications is using ALSA and the other PulseAudio, that also doesn't work. Assuming that your system uses PulseAudio, make sure that both Zoom and SSR are configured to use PulseAudio and not ALSA.

Last modified: Sat, 22 Aug 2020, 16:45 (GMT+1, DST)

Comment #5: Fri, 21 Aug 2020, 20:04 (GMT+1, DST)

Quote

I have tried to record a 'Zoom' meeting using Simple Screen Recorder. I have not been able to do so. Whenever Zoom turns on, Simple Screen Recorder is unable to record. Can this be fixed? Other than that Simple Screen Recorder works just fine. I have done several video tutorials using it.

Comment #6: Fri, 21 Aug 2020, 14:20 (GMT+1, DST)

Quote

See here. VAAPI requires an unusual method to transfer video frames which SSR does not support. Also, since I don't have any hardware to test it with, it's hard for me to add support for this.

Comment #7: Wed, 19 Aug 2020, 3:21 (GMT+1, DST)

Quote

Would you be able to support the h264_vaapi codec? Would be very greatful if you did decide to add it to the list of codecs... unless you already do so.

Comment #8: Fri, 14 Aug 2020, 22:02 (GMT+1, DST)

Quote

Banggood claims all kind of things, I would take their specs with a grain of salt. The actual gain is most likely comparable to other Pagoda-based designs. I also have no idea where they got that 50W spec from.

Last modified: Fri, 14 Aug 2020, 22:03 (GMT+1, DST)

Comment #9: Fri, 14 Aug 2020, 21:54 (GMT+1, DST)

Quote

I don't have time right now to resimulate the Triple Feed Patch Array for 5.25 GHz, but if you just take the existing design and scale everything up by a factor 1.105, you should get something reasonable. I've created some scaled PCBs for you here. Note that I have not simulated or tested these, so use them at your own risk.

Last modified: Fri, 14 Aug 2020, 21:55 (GMT+1, DST)

Comment #10: Fri, 14 Aug 2020, 19:04 (GMT+1, DST)

Quote

Hi, I see on the Banggood website they claim 5dBi gain. Having read your analysis of your original design, and having designed many experimental antennae myself, I am dubious, especially as you only claim 1dBi for the original design. So I was wondering whether you have had a chance to check their claims?

https://uk.banggood.com/Realacc-Pagoda-Antenna-RHCP-Right-Angle-5_8G-5dBi-50W-75mm-Omni-FPV-Antenna-SMA-or-RP-SMA-For-RC-Drone-p-1219943.html?rmmds=detail-top-buytogether-auto&ID=513344511532&cur_warehouse=CN

Regards,
Julian Grammer.

Julian at G1EKW <TakeThisOut> dot Radio

Last modified: Fri, 14 Aug 2020, 19:39 (GMT+1, DST)

Comment #11: Thu, 13 Aug 2020, 15:38 (GMT+1, DST)

Quote

Hey Maarten, thanks for your work. I am really a fan of your antennas.
But I just switched to Digital using OpenHD and most of wireless cards that we use are stronger in 5180-5320MHz. Any chance on providing designs for those lower 5GHz frequencies? I think we could benefit a lot from a Triple Feed Patch Array in this frequency range.

Last modified: Thu, 13 Aug 2020, 15:39 (GMT+1, DST)

Comment #12: Sat, 8 Aug 2020, 15:58 (GMT+1, DST)

Quote

Sorry, wrong file - the correct one is here. Because of the complexity of the model, it is split over multiple files:

• circular-patch-v10.hfss (patch antenna without feed network)

• circular-patch-feed-v2b.hfss (LHCP/RHCP feed network, pin_r2 = 4.05 mm)

• feed-network-v6.hfss (hybrid feed network, pin_r2 = 4.05 mm)

• sma-vertical-smd-v3.hfss (LHCP/RHCP feed network vertical SMA connector)

• sma-vertical-smd-v5.hfss (hybrid feed network vertical SMA connector)

It's a custom design, developed primarily by numerical optimization. I looked for existing hybrid designs but couldn't find anything that did what I needed. I started off with a 3-section branch-line coupler with an extra output, which gave me something that looked a bit like what I needed, and then just optimized the lengths and impedances hoping that it would converge to a reasonable result - and somehow that worked perfectly from the very first attempt. I started with ideal transmission lines in ADS to find the correct lengths and impedances that would give me the S-parameters I wanted, then converted that to a curved version in HFSS that matches the physical position of the feed pins, and re-optimized that one to compensate for the parasitic coupling that's created by placing all the tracks so close together.

I added the manual refinement steps mainly to improve the convergence speed by adding smaller elements near the copper edges (where the electrical fields are stronger), not because of the curvature. Without manual refinement HFSS needs a lot of automatic refinement steps before it stabilizes, and I noticed that the results weren't always equally accurate. This is a big problem when doing numerical optimization, it's actually preferable to have a large, consistent error than a small error that varies significantly between simulations, because if the error is consistent, it doesn't really affect the optimization process. Manual refinement seems to help a lot here, there's far less random 'meshing noise' in the simulation output because the meshing is more deterministic.

Comment #13: Sat, 8 Aug 2020, 9:01 (GMT+1, DST)

Quote

Hi Maarten, thanks for the fast reply - but the file you attached was from the pagoda antenna, what I would like to try is the triple feed patch antenna.
I know the Design will will be larger at 900Mhz, but as always it's the price to pay for good AR and Gain. But I've some approaches that I'll try for size reduction - folding the lines of the network and an additional dielectric block below the patch or a fractal approach for the patch should allow some shrinking in the structure.

Could you send me the hfss file for tripple feed patch ant (or one with the feed network)? I'm triying to figure out the spliiter function, is it some kind of combined simplified ratrace or how would you describe it?
Did you develop the network by yourself or is it an already published design?

By the way - I took a look at the Pagoda Design - I've seen that you used a length based refinement for the copper structures. Have you tried a surface approximation for the curved elements (I've made good results for curved geometries with a Surf approximation (normal deviation around 5deg) => select part, RMB, Surface Approximation, Manual Settings, Normal Deviation)

Best Regards
Florian

Comment #14: Fri, 7 Aug 2020, 23:55 (GMT+1, DST)

Quote

You can find them here. But I don't think the design will be very useful at 900 MHz, it would be very large which makes the PCBs rather expensive.

Last modified: Fri, 7 Aug 2020, 23:55 (GMT+1, DST)

Comment #15: Fri, 7 Aug 2020, 18:11 (GMT+1, DST)

Quote

Hi Maarten,

that’s a pretty cool design, specially the power divider. I would like to built one of this kind for a different antenna (in 900MHz ISM range).
You mentioned HFSS for simulation - would you share the HFSS Design files as well?

Best regards
Florian

Comment #16: Thu, 16 Jul 2020, 4:08 (GMT+1, DST)

Quote

If you can somehow mirror the entire design, then you will end up with the opposite polarization. But with the Pagoda antennas this isn't very practical, you could turn the PCBs upside-down but then the tracks will be on the wrong side, you won't be able to solder the coax to the top PCB, etc. I would just order a new set of PCBs, given how cheap they are. You can probably reuse the coax and connector.

Last modified: Thu, 16 Jul 2020, 4:09 (GMT+1, DST)

Comment #17: Thu, 16 Jul 2020, 1:53 (GMT+1, DST)

Quote

Is it possible to reverse the direction of a circumpolar antenna? I mistakenly ordered a handful of rhcp pagoda antennas while my receiving antennas are lhcp. Recently I've been looking into building my own antennas and am wondering if it's possible to to flip the antenna sets as to reverse them?

Comment #18: Sat, 11 Jul 2020, 23:05 (GMT+1, DST)

Quote

'Safe' is a relative thing - it will not damage the transmitter, however because of the ~10dB antenna gain, it will result in the equivalent of a 17W transmitter. This is a lot higher than the legal limit in most places (unless you have an amateur radio license, then different rules apply). Depending on the chosen frequency, your signal may cause interference with weather radar. This is less likely to be a problem if you stay within the ISM band though (5.725 – 5.875 GHz).

In any case I would suggest not standing directly in front of the antenna at close range if you do this. But power drops with the square of the distance, so simply moving 3x further away from it will reduce the power by 9x which is about the same as what you would have had with an omnidirectional antenna.

Last modified: Sat, 11 Jul 2020, 23:23 (GMT+1, DST)

Comment #19: Sat, 11 Jul 2020, 10:21 (GMT+1, DST)

Quote

The application is a home-grown chunk of C code. Uses XLib+Cairo to generate graphics, and invokes play (aka sox) to make sounds when required. I want to record the action before any sounds are made. The sounds record fine, but
it fails to record any video until the program invokes play (using the system() call).

The audio setup is based on jack, so I assumed that the audio route is sox->pulseaudio->jack->alsa with
SSR taking it from the pulseaudio jack sink. I guess that may be implying that it only starts recording
when the pulseaudio connection is made. I've never managed to understand how pulseaudio works.
Would I be better taking it via the Jack backend?

Switched to Jack backend, (record system speakers ticked) now works fine!

Clearly SSR must wait until something connect to pulseaudio before starting to record.

Thanks for the help, and for writing SSR!

Last modified: Sat, 11 Jul 2020, 11:03 (GMT+1, DST)

Comment #20: Sat, 11 Jul 2020, 0:07 (GMT+1, DST)

Quote

Hi, I've got an interesting application here.

My son is a Precision Rifle Shooting competitor. So he needs to practice out to like 600 yards.

What I've done is CAD'd up a case for an FPV camera and a 2W transmitter along with an FPV receiver/monitor. The camera will be down by the target and the receiver/monitor next to him.

I picked up a pair of these patch antennas, and have one installed on the receiver and it works great.

I just wanted to ask if it is safe to use the patch antenna on the transmitter as well. As the camera is static on a tripod, and can be aimed pretty decently towards the receiver as it is line of sight.

So the question is, is it OK to use this antenna on a transmitter.

Thanks.

Comment #21: Fri, 10 Jul 2020, 19:33 (GMT+1, DST)

Quote

I'm not sure what you mean - are you using the JACK backend in SSR and recording the PulseAudio JACK plugin?

If SSR doesn't start recording, it's usually because some other application is blocking access to the audio source. But that doesn't make much sense if the source is JACK, unless the JACK server is not running. Did you start the JACK server manually? And what is the application that you are trying to record?

Last modified: Fri, 10 Jul 2020, 19:36 (GMT+1, DST)

Comment #22: Fri, 10 Jul 2020, 17:30 (GMT+1, DST)

Quote

I've updated to 0.4.2 from the PPA. I'm using Pulseaudio Jack Sink as Audio input.

Still same effect - several seconds of mouse moving and clicking before I hit the 'GO' button,
and the video still only begins at that point.

Comment #23: Fri, 10 Jul 2020, 15:44 (GMT+1, DST)

Quote

That version is very outdated, try updating to the latest version from the PPA.

Which audio backend and source are you using?

Comment #24: Fri, 10 Jul 2020, 13:25 (GMT+1, DST)

Quote

Hi Maarten, I've just started using SSR and want to record a screen session. Followed through the dialogs and it
seemed to record OK, except the video only start when there is some audio output. I want to move the mouse around, select option then click on 'GO' and have all that in the video. Every time I try it the video always starts with clicking on
'GO'. I could click something else, but I don't want that included.

I'm running Linux Mint 19.3, and installed SSR from the distro. 'About' says it is 0.3.8.

Comment #25: Fri, 3 Jul 2020, 15:29 (GMT+1, DST)

Quote

Recording game audio using ALSA:
https://unix.stackexchange.com/a/310200

First, load the snd-aloop module:

sudo modprobe snd-aloop

This will create a new device called Loopback:

cat /proc/asound/cards
0 [PCH            ]: HDA-Intel - HDA Intel PCH
                     HDA Intel PCH at 0xc1814000 irq 60
1 [HDMI           ]: HDA-Intel - HDA Intel HDMI
                     HDA Intel HDMI at 0xc1810000 irq 61
2 [Loopback       ]: Loopback - Loopback
                     Loopback 1

From the information shown above we have to create two hw devices:

hw:0,0 (PCH is my main sound card).
hw:2,1 (The Loopback virtual device).

Normally, hw devices have the form: hw:X,Y. For our purposes, it seems that Y for the main card is always 0 while for the Loopback we have Y equals 1.

Now, in order to make all of this work, we need a ~/.asoundrc file with the following:

pcm.!default {
  type asym
  playback.pcm LoopAndReal
#capture.pcm looprec
  capture.pcm "hw:X1,Y1"
}

#pcm.looprec {
#    type hw
#    card Loopback
#    device 1
#    subdevice 0
#}

pcm.LoopAndReal {
  type plug
  slave.pcm mdev
  route_policy duplicate
}

pcm.mdev {
  type multi
  slaves.a.pcm pcm.MixReal
  slaves.a.channels 2
  slaves.b.pcm pcm.MixLoopback
  slaves.b.channels 2
  bindings.0.slave a
  bindings.0.channel 0
  bindings.1.slave a
  bindings.1.channel 1
  bindings.2.slave b
  bindings.2.channel 0
  bindings.3.slave b
  bindings.3.channel 1
}

pcm.MixReal {
  type dmix
  ipc_key 1024
  slave {
    pcm "hw:X1,Y1"
    #rate 48000
    rate 44100
    periods 128
    period_time 0
    period_size 1024 # must be power of 2
    buffer_size 8192
  }
}

pcm.MixLoopback {
  type dmix
  ipc_key 1025
  slave {
    pcm "hw:Loopback,0,0"
    #rate 48000
    rate 44100
    periods 128
    period_time 0
    period_size 1024 # must be power of 2
    buffer_size 8192
  }
}

Modify hw:X1,Y1 with the values for your main card (in my case hw:0,0).

You can test that this configuration works by playing something in your computer. If you hear it, so it is fine. Now let's play something in the computer, and record it from this virtual device with ffmpeg:

ffmpeg -f alsa -i hw:X2,Y2 -c:a libmp3lame -b:a 256k -vn capture.mp3

Where hw:X2,Y2 has to be replaced by the Loopback device, in this case hw:2,1.

[img]https://fastpic.ru/fullview/112/2020/0703/d30c0803168e0a8eff065f0fffcd6ea3.png[/img]

Last modified: Fri, 3 Jul 2020, 16:32 (GMT+1, DST)

Comment #26: Mon, 15 Jun 2020, 22:00 (GMT+1, DST)

Quote

The title is inaccurate, the gain is no different from any other Pagoda antenna. I suppose they think antennas with higher numbers will sell better.

Comment #27: Mon, 15 Jun 2020, 20:56 (GMT+1, DST)

Quote

Hi Marteen,

I'm very new to the hobby and trying to learn more about antenna, that's such a fascinating topic! I also stumbled about this 5 dbi pagoda antenna and I don't really get the 5dbi part, is it vertically flattened like the SkyHammer from VAS? I would also be interested to have your opinion on this

Thank you very much!

Vincent

Comment #28: Mon, 1 Jun 2020, 15:29 (GMT+1, DST)

Quote

Yes, it worked, thank you!

Comment #29: Thu, 28 May 2020, 15:58 (GMT+1, DST)

Quote

    buffer_clear(buff)
    buffer_write_uint8(buff,mid)
    buffer_write_uint32(buff, player_id)

    buffer_clear(buff_save) 
    if file_exists('test.txt') then 
    {
        buffer_read_from_file(buff_save,'test.txt')
        buffer_write_buffer(buff,buff_save)
    }
    else buffer_write_string(buff, 'null')

    socket_write_message(server, buff);

pid = buffer_read_unit32(buff)
psave= buffer_read_string(buff)

save_data = buffer_read_data(buff,buffer_get_length(buff) - buffer_get_pos(buff))
buffer_write_data(buffer_save,save_data)
buffer_write_to_file(buffer_save,'test.txt');

The problem is this:

save_data = buffer_read_data(buff,buffer_get_length(buff) - buffer_get_pos(buff))
buffer_write_data(buffer_save,save_data)

Although the data is not null-terminated, Game Maker cannot handle binary strings. It's Game Maker itself which is dropping part of the data, not the DLL. You need to use buffer_write_buffer_part to copy the data to buffer_save:

buffer_write_buffer_part(buffer_save,buff,buffer_get_pos(buff),buffer_get_length(buff) - buffer_get_pos(buff))

Last modified: Thu, 28 May 2020, 15:59 (GMT+1, DST)

Comment #30: Thu, 28 May 2020, 12:16 (GMT+1, DST)

Quote

Made new code on client:

    buffer_clear(buff)
    buffer_write_uint8(buff,mid)
    buffer_write_uint32(buff, player_id)

    buffer_clear(buff_save) 
    if file_exists('test.txt') then 
    {
        buffer_read_from_file(buff_save,'test.txt')
        buffer_write_buffer(buff,buff_save)
    }
    else buffer_write_string(buff, 'null')

    socket_write_message(server, buff);

And this on server:

pid = buffer_read_unit32(buff)
psave= buffer_read_string(buff)

save_data = buffer_read_data(buff,buffer_get_length(buff) - buffer_get_pos(buff))
buffer_write_data(buffer_save,save_data)
buffer_write_to_file(buffer_save,'test.txt');

This faild, file on server is still only a part of original.
If I understood correctly buffer_read_data and buffer_write_data are not null-terminated, and could be used in my case. But there is no expamples on how does it work. How does work buffer_get_length(buff); buffer_get_pos(buff), and at what point should I calculate the end of a buffer? When do buffer understand, if I want it to read from a specific position? Would buffer_read_data work like I think? Where can I find more code examples to understand, how to use it?

Last modified: Thu, 28 May 2020, 12:22 (GMT+1, DST)