Hi, glad to hear you are checking it out. Although, I cannot replicate the problem. When you say the blocks are missing, do you mean when you open it up they are? If they are missing you would not be able to run the graph, which makes me think maybe you are running it with the fopsher sink in place, but no fopshor support. The graph will not properly run without opencl/nvidia/amd support setup beforehand. You can disable the fosphor sink and configure a qt gui freq sink instead but then it is very difficult if not impossible to visually see the burst.
If I am way off let me know, please take a screen shot if you can. I just started up the ISO live to check on my end.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks. The "gr-droneid" blocks all show up as red in gnuradio-companion,
so I can't run the graph.
fospher works fine, I just made a quick new flowgraph that just dumps into
that from my Ettus and everything works as expected.
Taking a look around the image I can't find the actual source of
"gr-droneid" anywhere, so I can't rebuild it to reinstall it. Is it in
source control anywhere I can try to build it? If it's not quite ready for
prime time maybe I should just hang tight and wait for that :) All good
keen to see it some day!
Hi, glad to hear you are checking it out. Although, I cannot replicate the
problem. When you say the blocks are missing, do you mean when you open it
up they are? If they are missing you would not be able to run the graph,
which makes me think maybe you are running it with the fopsher sink in
place, but no fopshor support. The graph will not properly run without
opencl/nvidia/amd support setup beforehand. You can disable the fosphor
sink and configure a qt gui freq sink instead but then it is very difficult
if not impossible to visually see the burst.
If I am way off let me know, please take a screen shot if you can. I just
started up the ISO live to check on my end.
Looks like /usr/src/dji_droneid/gnuradio/gr-droneid/lib et al is missing.
All good if that is not provided, just would be good to know, so can stop
troubleshooting at this point.
Thanks. The "gr-droneid" blocks all show up as red in gnuradio-companion,
so I can't run the graph.
fospher works fine, I just made a quick new flowgraph that just dumps into
that from my Ettus and everything works as expected.
Taking a look around the image I can't find the actual source of
"gr-droneid" anywhere, so I can't rebuild it to reinstall it. Is it in
source control anywhere I can try to build it? If it's not quite ready for
prime time maybe I should just hang tight and wait for that :) All good
keen to see it some day!
Hi, glad to hear you are checking it out. Although, I cannot replicate
the problem. When you say the blocks are missing, do you mean when you open
it up they are? If they are missing you would not be able to run the graph,
which makes me think maybe you are running it with the fopsher sink in
place, but no fopshor support. The graph will not properly run without
opencl/nvidia/amd support setup beforehand. You can disable the fosphor
sink and configure a qt gui freq sink instead but then it is very difficult
if not impossible to visually see the burst.
If I am way off let me know, please take a screen shot if you can. I just
started up the ISO live to check on my end.
Im replying from my phone, so bear with me. I see the attachment and can't explain why that is happening for you. Which build of DragonOS are you using? Can you burn this to USB and try it live, open the flow graph that is https://drive.google.com/drive/folders/19TJiEfcqX9qSAVsWiaUe-5bdMGMiZUo7
On the point of source, that is my bad. I tried to keep the git control in place and the developer has two, now three branches in place. You could try on yours to do a sudo git checkout of the normal gr-droneid branch which i think will populate the gr-droneid folder with more than just the build folder. You could then try to rebuild, make install. Then change back to the previous branch.
I have been holding off switching to his new dji drone id branch, but for now i have tested everything and found it working.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ahhh, I see "gr-droneid" comes from the "gr-droneid-update" branch, but you
have the default branch checked by default with a nice flowgraph you
provide. The "gr-droneid" block has already been installed from the other
branch, and the build directory was just left behind. OK great I'll debug
that more tomorrow. Thanks,
Im replying from my phone, so bear with me. I see the attachment and can't
explain why that is happening for you. Which build of DragonOS are you
using? Can you burn this to USB and try it live, open the flow graph that
is https://drive.google.com/drive/folders/19TJiEfcqX9qSAVsWiaUe-5bdMGMiZUo7
On the point of source, that is my bad. I tried to keep the git control in
place and the developer has two, now three branches in place. You could try
on yours to do a sudo git checkout of the normal gr-droneid branch which i
think will populate the gr-droneid folder with more than just the build
folder. You could then try to rebuild, make install. Then change back to
the previous branch.
I have been holding off switching to his new dji drone id branch, but for
now i have tested everything and found it working.
In the very top level directory do a sudo git checkout gr-droneid
(Thats from memory, i hadnt used the update branch yet). That should populate the gr-droneid folder with everything. Ill check when i get back too. I just cant figure out why your blocks are broke and mine are not. Maybe an older ISO you have, but i dont think i put one out without it built.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Finally got a second to check, so changing into /usr/src/dji_droneid
and running sudo git checkout gr-droneid
and then checking dji_droneid_gnuradio/gr-droneid shows all folders populated.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks. That restores that branch, but I see reinstalling it that time_sync
doesn't write any bursts with prefix "file_" because the relevant call to
write_samples() is commented out and has the wrong size parameter. Easily
fixed there. I see the gr-droneid branch and gr-droneid-update branches
have drifted somewhat from upstream, makes sense - I'll look at that later.
It looks like the demodulation block crashes on about 1/5 blocks
(segfault). I'll try to track that down. I'll try the octave path now on a
raw recording here and hope for the best, now that I see some bursts.
I did download DragonOS again, which fixed the original missing blocks
issue - I must have had a bad download/thumb drive (I just replaced both).
However, debugging the liveCD is a bit painful, so I built another VM with
the latest gnuradio maint-3.8 and gr-fosphor (to avoid gr-droneid's
dependency on swig versus pybind). Also painful but at least I can do that
without swapping out the entire OS.
Thanks for the assist getting things mostly up and running and also taking
the time to document the process overall, that's really nice! Definitely on
the cutting edge here.
Finally got a second to check, so changing into /usr/src/dji_droneid
and running sudo git checkout gr-droneid
and then checking dji_droneid_gnuradio/gr-droneid shows all folders
populated.
The two tickets with alphafox02 is me, you'll also find the others explaining the crashes etc. There's a lot being improved in the update branch. Creating the directory for bursts to allow the graph to run in tmp, you'll also need to create a directory for octave to run properly and I can't recall the path (i mention it in the video I put together). For sure doing the 4-5GB captures got results and then someone wrote me up a python based tool to extract the info into a human readable format .
I think for the next update, I'll move to the gr-droneid update branch. Those branches really only see changes to the GNU Radio portion while the main/master seems to work on other areas. Kind of confusing, I'd expect maybe at some point the gnuradio radio update branch to merge into main.
If you find anything I should change or include, please let me know.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One other thing, if you switch to the gr-droneid update branch, you might not even need octave. All the work is setup to be done within GNU Radio itself. You should see the decoded frames bottom left hand corner, that's my understanding. From there, just convert the frame info to human readable. I think maybe over the next couple days I'll switch, but I need to get another DJI to test with.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, glad to hear you are checking it out. Although, I cannot replicate the problem. When you say the blocks are missing, do you mean when you open it up they are? If they are missing you would not be able to run the graph, which makes me think maybe you are running it with the fopsher sink in place, but no fopshor support. The graph will not properly run without opencl/nvidia/amd support setup beforehand. You can disable the fosphor sink and configure a qt gui freq sink instead but then it is very difficult if not impossible to visually see the burst.
If I am way off let me know, please take a screen shot if you can. I just started up the ISO live to check on my end.
Thanks. The "gr-droneid" blocks all show up as red in gnuradio-companion,
so I can't run the graph.
fospher works fine, I just made a quick new flowgraph that just dumps into
that from my Ettus and everything works as expected.
Taking a look around the image I can't find the actual source of
"gr-droneid" anywhere, so I can't rebuild it to reinstall it. Is it in
source control anywhere I can try to build it? If it's not quite ready for
prime time maybe I should just hang tight and wait for that :) All good
keen to see it some day!
On Tue, Jul 5, 2022 at 8:54 PM Cemaxecuter cemaxecuter@users.sourceforge.net wrote:
Related
Tickets: #22
Looks like /usr/src/dji_droneid/gnuradio/gr-droneid/lib et al is missing.
All good if that is not provided, just would be good to know, so can stop
troubleshooting at this point.
On Tue, Jul 5, 2022 at 9:01 PM Bailey, Josh josh@vandervecken.com wrote:
Related
Tickets: #22
Im replying from my phone, so bear with me. I see the attachment and can't explain why that is happening for you. Which build of DragonOS are you using? Can you burn this to USB and try it live, open the flow graph that is https://drive.google.com/drive/folders/19TJiEfcqX9qSAVsWiaUe-5bdMGMiZUo7
On the point of source, that is my bad. I tried to keep the git control in place and the developer has two, now three branches in place. You could try on yours to do a sudo git checkout of the normal gr-droneid branch which i think will populate the gr-droneid folder with more than just the build folder. You could then try to rebuild, make install. Then change back to the previous branch.
I have been holding off switching to his new dji drone id branch, but for now i have tested everything and found it working.
Ahhh, I see "gr-droneid" comes from the "gr-droneid-update" branch, but you
have the default branch checked by default with a nice flowgraph you
provide. The "gr-droneid" block has already been installed from the other
branch, and the build directory was just left behind. OK great I'll debug
that more tomorrow. Thanks,
On Tue, Jul 5, 2022 at 9:49 PM Cemaxecuter cemaxecuter@users.sourceforge.net wrote:
Related
Tickets: #22
In the very top level directory do a sudo git checkout gr-droneid
(Thats from memory, i hadnt used the update branch yet). That should populate the gr-droneid folder with everything. Ill check when i get back too. I just cant figure out why your blocks are broke and mine are not. Maybe an older ISO you have, but i dont think i put one out without it built.
Finally got a second to check, so changing into /usr/src/dji_droneid
and running sudo git checkout gr-droneid
and then checking dji_droneid_gnuradio/gr-droneid shows all folders populated.
Thanks. That restores that branch, but I see reinstalling it that time_sync
doesn't write any bursts with prefix "file_" because the relevant call to
write_samples() is commented out and has the wrong size parameter. Easily
fixed there. I see the gr-droneid branch and gr-droneid-update branches
have drifted somewhat from upstream, makes sense - I'll look at that later.
It looks like the demodulation block crashes on about 1/5 blocks
(segfault). I'll try to track that down. I'll try the octave path now on a
raw recording here and hope for the best, now that I see some bursts.
I did download DragonOS again, which fixed the original missing blocks
issue - I must have had a bad download/thumb drive (I just replaced both).
However, debugging the liveCD is a bit painful, so I built another VM with
the latest gnuradio maint-3.8 and gr-fosphor (to avoid gr-droneid's
dependency on swig versus pybind). Also painful but at least I can do that
without swapping out the entire OS.
Thanks for the assist getting things mostly up and running and also taking
the time to document the process overall, that's really nice! Definitely on
the cutting edge here.
On Wed, Jul 6, 2022 at 11:46 AM Cemaxecuter cemaxecuter@users.sourceforge.net wrote:
Related
Tickets: #22
Glad to hear you're up and going. Most of what you're seeing/finding is being talked about here.
https://github.com/proto17/dji_droneid/issues?q=is%3Aissue+is%3Aclosed
The two tickets with alphafox02 is me, you'll also find the others explaining the crashes etc. There's a lot being improved in the update branch. Creating the directory for bursts to allow the graph to run in tmp, you'll also need to create a directory for octave to run properly and I can't recall the path (i mention it in the video I put together). For sure doing the 4-5GB captures got results and then someone wrote me up a python based tool to extract the info into a human readable format .
I think for the next update, I'll move to the gr-droneid update branch. Those branches really only see changes to the GNU Radio portion while the main/master seems to work on other areas. Kind of confusing, I'd expect maybe at some point the gnuradio radio update branch to merge into main.
If you find anything I should change or include, please let me know.
One other thing, if you switch to the gr-droneid update branch, you might not even need octave. All the work is setup to be done within GNU Radio itself. You should see the decoded frames bottom left hand corner, that's my understanding. From there, just convert the frame info to human readable. I think maybe over the next couple days I'll switch, but I need to get another DJI to test with.