I didn’t do the changes in rc.local, just the chron ones, so there is no log.
I’m not asking you to change rc.local just create a file named socat.sh and paste the stuff in there that i wrote (the 2 while loops and the other stuff) which would also populate the log file.
Name the file socat.sh and call it from rc.local or cron it doesn’t matter.
Socat needs a wrapper script, just calling it by itself is not gonna do what you want.
Ah, OK, I missunderstand. That worked.
However, in the piaware logs I see this now:
[2018-10-27 12:19 EDT] mlat-client(619): Warning: the timestamps provided by your receiver do not seem to be self-consistent. This can happen if you feed data from multiple receivers to a single mlat-client, which is not supported; use a separate mlat-client for each receiver.
Yeah because piaware gets its data on port 30005 and you said you wanted dump1090-fa to output it’s data there (–net-bo-port).
So naturally dump1090-fa will also send the socatted data from the flightfeeder to piaware.
If you want to have more than one receivers data on the dump1090-fa the piaware needs to get its data directly from airspy and not from dump1090-fa.
The airspy sends it only to 30104.
dump1090-fa connects that to 30005, if I don’t, then faup doesn’t get that data to send to FA servers?
I’ll delete that 30005 from dump1090-fa, to see what happens.
Yep, not the fr24 doesn’t get anything from that port and piaware log says:
[2018-10-27 12:36 EDT] no ADS-B data program is serving on port 30005, not starting multilateration client yet
[2018-10-27 12:36 EDT] no ADS-B data program seen listening on port 30005 for 63 seconds, next check in 60s
So you reenable the listen 30005 on airspy obviously i thought that was implicit 
But then, all this data that I bring in from the other Pi (on port 30004/30104) doesn’t get sent to FA/FR24 servers anymore, only the airpsy data.
FR24 has MLAT as well, that would cease functioning as well.
FA alreay gets the flightfeeder data.
Well, that cancels the local MLAT. I didn’t want that.
I’ll try without injecting the 30105 data.
LE: That seems to work.
So you are back to the configuration of before you rewrote you sd-card?
Anyway good that the shell script misunderstanding is gone.
The SD card didn’t let me use the dump1090 as server for 30005, I had to use the airspy to do that.
Difference is that now the 30005 port presents the data from both receivers (to go to FA and FR24).
And why would you want to?
By serving the received data directly with airspy listen 30005 you have dump1090-fa free to display the additional data from the other receiver via socat.
Data from two receivers can never be fed to FA or FR24 with one feeder without disabling MLAT.
Also i noticed you don’t have crc correction enabled for the airspy (use -f 1 as an additional option)
It will get you quite a few more messages.
Don’t use more than one on that option though it gives bad data.
Edit: i guess my mindset is just different wanting to display all the available data on the local map while you might just want to increase the stat numbers 
The socat stuff indeed won’t help with that.
That’s all good, I wanted both of them
And thanks for the tip for crc correction!
@SoNic67 I have been away ( out of country with poor internet) for more than a month and wanted to check on how your install is holding up ? I may try to replicate your solution here, anything you would do differently ?
I waited till the leaves dropped on the non pine trees and find that leaf cover itself being gone didn’t really “move the needle” in terms of improving reception with existing antenna locations, so I will need to seek altitude.
hello skip, i too was hoping that winter and the loss of leaves would show improvement. i live surrounded by a mix of hardwoods and pine trees. please see the attached paper (look on page 3, right hand column re pine trees and needle length)https://www.researchgate.net/publication/291973340_Adverse_Impacts_of_Forestation_on_RF_Energy_Propagation_%27An_Experimental_Approach
@retman1222, thanks for the link. I had read some discussions previously regarding effects on things such as cell antennas and other commercial radio installs being affected by forested terrain. There’s definitely some impacts on my reception here.
Just for grins I measured the pine needles from two different species of trees that are here.
One with short needles measured 98mm , and the longer needled needles measure 183 mm. I estimate that the velocity factor for a wet pine needle is around .03 and that each tree has an average of 451,000 pine needles on it. using a few assumptions for what antenna form the mass of needles represents we can quickly come up with a method for a solution that produces the desired results: What is needed is to tune the pine trees overall length by trimming, starting at the base of the tree and working upwards. The more the tree is cut, the lower the attenuation and of course this effect is cumulative, meaning that cutting/tuning additional trees further improves reception.
Sorry about my sense of humor, but I have thought about cutting a number of the trees as they have gotten way too large and are causing other issues.
1 Like
It seems you have it the wrong way round. There is a Patent issued for a Tree Antenna. You should be using the tree as the antenna rather than cutting it down.
Let us know how that works out for you.
Here is The Patent Document
S.
yes, i have attempted this approach but the words of my wife come back to me…“you are absolutely NOT cutting ANY trees down”!
I think there is a big difference between trimming trees and cutting them down.
If the trees around here are above a certain dimension then a permit (fee) must be obtained before it can even be trimmed.
Why is a Tree Work Permit required?
A few years ago I had to pay for a permit for the Council tree man to inspect a fallen tree before I could have it removed and get at what was once a shed underneath. Two weeks wait for an appointment to inspect a fallen tree and judge if it was appropriate to remove it.
Council is way worse than wife.
S