Hopefully the antenna would work well in terms of gain and SWR when transmitting across the specified frequency range. How it works outside that is not specified - typically the performance degrades.
But antennas are generally specified in terms of how they handle desired signals, not what they do with undesired ones. Unless there’s a bad connection causing rectification, handling undesired energy is really the job the the receiver’s front end, not the antenna.
I’ll ask for a refund on my new antenna then. Doesn’t seem like it will be worth the hassle of installation if the existing 850-2100mhz one will be suffice. I was always worried for potential noise as 850-914 is used by a mobile carrier here.
The new antenna may well be better, but in terms of putting the transmitter energy out onto the air, rather than bouncing it back up the cable where it will heat up the power amplifier.
When considering RAK2247 with Linux PC, keep in mind that uses code discontinued by Semtech in 2015. Semtech discontinued the code with good reason (timing inaccuracies due to the USB to SPI translation which cause scalability issues)
Then it’s important to note that the RAK2247 comes in both SPI and USB versions, and the concern mentioned there is specific to the USB version which someone would probably pick if they had a Linux “PC” vs. a Linux “embedded board” likely to have an SPI channel.
If you can use SPI, be sure you order the SPI version of the RAK2247. Unlike the RAK833 where the USB model also supported SPI, for the 2247 you have to specifically chose the SPI version at order time. You do have to slow the clock speed to account for a poorly chosen and unnecessary level translator in the 2247, but that doesn’t really cause problems the way the latency of an FT2232 USB interface does.
If you need to use a USB interface because your host system is constrained, pick a “pico GW” design which uses an MCU to accomplish the tighter timing tasks. nFuse makes them, one of the Heltec offerings might also have this capability but you’d have to check carefully. The picoGW code from Semtech code forces slightly longer timings than the native SPI code, but not by much. Also note that it is unfortunately a different packet forwarder codebase (though if you do a full diff, not terribly different), so if you want to use a packet forwarder that has been modified from the Semtech original, you may need to spend some time patching before it will work with the pico GW interface code.
That’s precisely what is not recommended, as the USB latency really limits agility on a busier network
For picoGW solutions which are sensible I should also mention that the nFuse seems to have compatibility issues with some internal mPCIe slots. You might consider it, but in an external holder connected to a USB port.
It’s unlikely your embedded PC supports SPI. Certainly not on the mPCIe connector - there isn’t even a standard pinout for that, because SPI is not part of the mPCIe spec the way that USB is.
I thought you were asking about the embedded PC chassis.
The FT2232 USB based LoRa Concentrators are obsolete configurations sustained by demand of customers uninformed enough to buy something better like the SPI configuration, or if they must use USB, the pico GW design that Semtech engineered precisely to solve that problem.