rad1o / f1rmware Goto Github PK

When executing the rgb_leds binary and selecting one of the listed files the rgb_leds program is closed and im back in the menu. (LED colors are not changing)

Any clues what that could be?

Tests should include:

Charge current measurement
Voltage at which the charging stops
Test that all status pins read the correct value
Stop charging when the battery gets hot
Test maximum current, drawn from the USB sockets.

We get no info about the cpld state (programmed or even turned on). Need to find out if we can get any info.

Firmware that was build with gcc-arm-none-eabi 5.4.1+svn241155-1 and later that ships with Ubuntu 17.10 apparently produces a defective firmware image.
17.04 and 16.10 were not tested, but the toolchain from 16.04 works.

The firmware was flashed in DFU mode with smartflash, the FlashApp binary still seems to work, but the rad1o screen stays black after power reset, and booting into the MSC mode doesn't work as well.

data sheet says not to write to it until sys_init is done.

Hey guys,
just prepared my system to be ready for the rad1o when I arrive at the campsite. Had to install cmake, maybe this should be added to the dependencies?

We want to sample the microphone, and some external voltages.

The microphone might need hardware modifications (jumpers, resistors) next to the headset connector.

Under https://github.com/rad1o/f1rmware/blob/master/doc/debugging.md it is mentioned that USB serial should be possible, and that the testapp -> CDC does something with this.

I tried to

• Run udevadm monitor on computer (Linux 4.1) to observe for devices being connected
• Power the rad1o, go into testapp, start CDC. Poke joystick around.

Expected:

• To see a serial device on computer.
• That CDC app writes something helpful to LCD screen

Actual:

• No serial devices is seen on computer.
• Nothing is shown on LCD screen (stays in menu)
• The rad1o freezes, need to reboot to go to another app

Tested both USB ports. Tested on two different devices. Running f1rmware from git. MSC mode works fine.

In development I had problems reading the file so that 0 was returned by the atoi function in https://github.com/rad1o/f1rmware/blob/master/l0dables/snake.c#L335.
I found out that reading the variable helps (see https://github.com/rad1o/f1rmware/blob/master/l0dables/snake.c#L333), but now in production it still cannot read the file...
Does someone know, what's the matter and how to fix it?

PS: Saving the file works without problems, loading returns 0, which results in a displayed highscore of 1 on each game start, see https://github.com/rad1o/f1rmware/blob/master/l0dables/snake.c#L75.

Lets play some music.

This needs a hardware modification. On the prototype, the pin where the LEDs are connected is not a GPIO.

When using hackrfapp, it uses nice big fonts to show some parts of its status. Everything works well and looks nice, good job :)

However, right after issuing "hackrf_info" on host PC, all the font immediately change to built-in one and it stays that way until restarted - even when status changes, everything is updated on the screen in the built-in small font.

I've taken a quick look at the source, but couldn't find anything that looked related. Looks like setExtFont from that point on simply fails to open and read the font file properly.

Anyone have some idea about what could be the cause?

"make flash" requires the dfu-util that is marked optional above.

Please change the tutorial to something like this:

To flash the firmware permanently, simply copy the .bin file to the mounted mass storage rad1o.
If you want to just run the firmware once without permanently storing it on the rad1o, you will need the dfu-util mentioned above and run the "make flash" command.

Setting the F_ZEROS flag for IntToStr (itoa.c) has no effect

The rad1o contains a l0adable for the fahrplan from camp. I would like to have the schedule for 32c3 also. It looks like a pretty straightforward change to add this to the menu, but we need the equivalent of files/fahrplan.scd for the congress. Does anyone have details on this file format or an easy way to generate it? Even a json endpoint or someother machine-parseable format to work off of would be helpful.

Test at least one LCD with a green or a brown one flex cable.

Also test the PWM backlight driver

Snake2 creates blocks on the left of the left blue line.
A fix would be to change the size of the field.
With #define MIN_X 2 I can't see the issue again, but I'm not sure if that is a reasonable fix?

needs to be looked into.

vdd_fix support in bootmenu

need to add iggys color chooser to the firmware

Are there plans to adept the changes of the new HackRF release?
Is this even possible the slightly different hardware of the rad1o?

I would like to detect it on the protocol level (MSC unmount, CDC close), but found no way.

As a workaround the hardware USB disconnect would be possible, but I haven't even found a way to do this yet.

Any hints welcome

Update https://github.com/rad1o/hackrf/blob/510dde748510dd83ed1402397e11e2cfd9117b91/firmware/hackrf_usb/usb_descriptor.c#L34 to use 0xCC15 since all the HackRF library files have been updated to use this in the last commit (ref: https://github.com/mossmann/hackrf/pull/200/files).