Multiple crashes going on

ImDroided commented 6 years ago

Ok so I just compiled and the firmware is crashing on the following requiring me to hit the reset switch.

Transmitters: Signal Generator Soundboard TEDI/LCR AFSK And the touch tunes remote is now crashing after it loads the screen and I touch a button on the screen or if I try to use the buttons or dial on the portapack.

Great work.

furrtek commented 6 years ago

Those modifications on the MenuView didn't go so well...

fantuz commented 6 years ago

Here the behaviour i can see:

from the RX menu, you can always come back
sometimes you cannot go back to main after TX (and sometimes TX stuck ON)
sometimes after TX, even if TX might stop, no way to get back to main menu.... this is quite constant as far as i tested
If you Record a file to SD, not going back to main menu even if you correctly stop the recording.
replay, stuck as well, only after Replay play button

On Sat, Dec 9, 2017 at 2:07 AM, Furrtek notifications@github.com wrote:

Those modifications on the MenuView didn't go so well...

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/furrtek/portapack-havoc/issues/134#issuecomment-350410813, or mute the thread https://github.com/notifications/unsubscribe-auth/AHMhMu1UWIhJp6EdSaxDEEdIe268O3pAks5s-d1XgaJpZM4Q7yfu .

--

Massimiliano Fantuzzi IT professional, expert in DB Linux and networks.

+41 76 754 1037 <%2B41%2076%20754%201037>

furrtek commented 6 years ago

The problem is related to pointers to objects being deleted, so it's "normal" that everything goes crazy once that happens (at startup probably, since the menu is the first thing you see). I'm currently searching why that happens, sorry.

furrtek commented 6 years ago

Things seem back to normal after 2d01822cdb0595d519910123a70a349e078e00fb ? Was calling methods of inexistent objects on menu show/hide...

F0GPI commented 6 years ago

hi furrtek, for your information, in the last release, a bug appear on soundboard (freezing), also on jammer and load frequency on all modes (tx&rx), and rolling to KDR444 (freezing) too.

fantuz commented 6 years ago

i did get frozen on the SUBARU fob TX. it happens as soon as i click BACK arrow

testing the rest of menus but seeing @F0GPI comment, I guess some rework still needed. Thanks @furrtek for all the support !

PS: bravo pour SSTV ++

furrtek commented 6 years ago

@F0GPI Hello, the soundboard issue is a separate one which appeared earlier (#110).

I can load and save in the frequency manager but going to some categories (KDR444 or JAMMER) sometimes freezes on my unit also. I'm looking into that...

@fantuz I can't get the keyfob TX to freeze, even after transmitting. Is there a particular sequence you follow from the Portapack's startup ?

Thanks a lot for the reports.

furrtek commented 6 years ago

There should be no more freezes in the frequency loading screen since 70c7646743ffc7af229bc8df8949b69feb23ecdc. Temporary fix...

fantuz commented 6 years ago

Hello @furrtek I confirm it still happens in "key fob" after doing a "panic tx" short test, yes, still not able to go back, plus it really freezes.

I set the screensaver backlight to 10 minutes

fantuz commented 6 years ago

burger pager does the same, latest firmware obviously.

in that case, the STOP button is not effective, and the BACK button stops TX LED but then no going back (freeze)

PS: just for info, long time ago i have inserted a "blacklist hackrf" in my "modules.d" as I compile from sources. Might it be related ? Just wondering.

fantuz commented 6 years ago

Hello @furrtek

YES, basically every TX item still freezes for me (tried subaru, keyfob, lights).

Just for the note, another test I did was to recompile new hackrf sources (i was one or two commits behind, nothing major) and then re-uploaded latest firmware from hackrf built...

My environment haz latest HAVOC, latest HACKRF, latest GQRX and latest GR-osmo/etc just because i update more or less all the radio environment at once (including gnuradio).

Here the behaviour:

GQRX works very well BEFORE re-flashing HAVOC.
- then reflashed and "make program".
- still, many TX are bad or freezing (but i can't say is worst than before as i took no notes) as we discussed few days ago
- if i choose to go "hackrf-mode", the device will pop up correctly and be available to choice in GQRX, so i press PLAY and the acquisition will proceed as usual .... but .... all black and absolutely no signal coming in.... but is playing, so device correctly recognized etc.

I posted in #78 a guess about the hackrf hardware version, are we all talking about ANY portapack plus ANY hackrf, is it right? there exist different "hackrf versions" as one was the kickstarter/demo and one the final product, at least. Is portapack too, still the very same in terms of hardware ? I bought it few days ago from Rysc Corp.

Cheers !

F0GPI commented 6 years ago

Thanks, the soundboard app works veryouell !!

fantuz commented 6 years ago

See the original issue on portapack-hackrf to see what I mean -> https://github.com/sharebrained/portapack-hackrf/issues/115

Impossibility to go on hackr-mode correctly. Device found, gqrx allows to start DSP, but is mute (you can change frequency and gain, but no way to "use" the hackrf outside of portapack-firmware.

Available to test

fantuz commented 6 years ago

Persisting behaviour on Ubuntu 16 Ubuntu 17 (not tested on the Ubuntu 14 before release-upgrade).

Tested with boost 64 homemade, boost 63 and boost 62 from repos. Also tested on boost 58, same issues.

HackRF mode doesn't work for me!

ImDroided commented 6 years ago

I just compiled and everything is working for me. What happens if you flash the original hackrf firmware?

On Dec 24, 2017 9:32 AM, "Massimiliano Fantuzzi HB3YOE" < notifications@github.com> wrote:

Persisting behaviour on Ubuntu 16 Ubuntu 17 (not tested on the Ubuntu 14 before release-upgrade).

Tested with boost 64 homemade, boost 63 and boost 62 from repos. Also tested on boost 58, same issues.

HackRF mode doesn't work for me!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/furrtek/portapack-havoc/issues/134#issuecomment-353790332, or mute the thread https://github.com/notifications/unsubscribe-auth/ANVzaWPyPz5WPkn2l8Cto6VCVZ6OhxLcks5tDm6kgaJpZM4Q7yfu .

ImDroided commented 6 years ago

Or even the original portapack firmware

On Dec 24, 2017 9:59 AM, "imdroided@gmail.com" imdroided@gmail.com wrote:

I just compiled and everything is working for me. What happens if you flash the original hackrf firmware?

On Dec 24, 2017 9:32 AM, "Massimiliano Fantuzzi HB3YOE" < notifications@github.com> wrote:

Persisting behaviour on Ubuntu 16 Ubuntu 17 (not tested on the Ubuntu 14 before release-upgrade).

Tested with boost 64 homemade, boost 63 and boost 62 from repos. Also tested on boost 58, same issues.

HackRF mode doesn't work for me!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/furrtek/portapack-havoc/issues/134#issuecomment-353790332, or mute the thread https://github.com/notifications/unsubscribe-auth/ANVzaWPyPz5WPkn2l8Cto6VCVZ6OhxLcks5tDm6kgaJpZM4Q7yfu .

fantuz commented 6 years ago

Hi @ImDroided !

with original FW, works like a charm (no need to remove the portapack anyway) flashing portapack (havoc or hackrf) is OK but HACKRF-mode is KO.

I also have clock IN (via GPSDO) so "hackrf_debug --si5351c -n 0 -r" returns 0x01 in place of 0x51

Portapacks HAVOC and HACKRF suffer the same issue to me. Might the CLPD be different between different releases of one, jawbreaker and so on?

I own the final version of HACKRF (not the kickstarter) and 20170522 is the date on my portapack HW.

fantuz commented 6 years ago

Just to clarify, its been 3 years I compile and use BladeRF Airspy, GQRX and similar. 13 years on Linux and CLI, IT is the way I pay bills :)

I understand we need to be able to reproduce errors in order to debug them. Just I am saying that I am currently experiencing problems with the mentioned softwares.

Yes, is cross portapack-havoc and portapack-hackrf to me.

linux; GNU C++ version 7.2.0; Boost_106200; UHD_003.010.002.000-19-gd9561315
gr-osmosdr v0.1.4-98-gc653754d (0.1.5git) gnuradio 3.7.12git-295-ga0adcd33
built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy redpitaya 
Resampling audio 96000 -> 48000
BookmarksFile is /home/max/.config/gqrx/bookmarks.csv
gr-osmosdr v0.1.4-98-gc653754d (0.1.5git) gnuradio 3.7.12git-295-ga0adcd33
built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy redpitaya 
Using HackRF One with firmware git-3447863

and the suggested command by @jboone in the original portapack-hackrf-thread, doensn't work either (hackrf_transfer)

that command is clear to me, the same for RTLSDR or airspy_rx, jolly clear but it wont work when using this firmware.

the acqusisiton DSP worked and still works like a charm on the different systems, boosts, and SDR platforms (not only the HACKRF).

can I help ?

furrtek commented 6 years ago

I have the "old" 20140826 Portapack and I can confirm everything still works fine here with SDR# and GQRX. Can you try going in the audio receiver in any mode, exit, and directly go in HackRF mode ? Can you also do the same but just after having transmitted something ? Is there any difference ? Still mute ?

jboone commented 6 years ago

@fantuz I just noticed you are using an external clock input (from a GPS disciplined oscillator). Do you see the HackRF mode not work if you set up your system without the GPSDO attached? I am wondering if that is a significant variable that is different between your setup and ours.

furrtek / portapack-havoc

Multiple crashes going on #134