- Welcome to Olimex Support Forum.
Olimex Support Forum
Recent posts
#1
A20 / Re: Persistent keymap doesn't ...
Last post by oly - October 08, 2026, 07:32:35 PMHello,
Thank you for your help.
I confirm it is the /etc/default/keyboard file (corrected in my initial post).
I'll try this ASAP and let you know.
Thank you for your help.
I confirm it is the /etc/default/keyboard file (corrected in my initial post).
I'll try this ASAP and let you know.
#2
A20 / Re: Persistent keymap doesn't ...
Last post by LubOlimex - October 08, 2026, 08:43:52 AMFirst, can you confirm whether the filename is /etc/default/keyboard rather than /etc/default/keymap?
Please then try:
If this changes the keyboard to French, reboot and check again. keyboard-setup.service can load a compiled keymap from /etc/console-setup/; that cached map may still contain the original US configuration. If reboot still restores US, please post what you get with these:
Please then try:
Quotesudo setupcon --save-only
sudo systemctl restart keyboard-setup.service
If this changes the keyboard to French, reboot and check again. keyboard-setup.service can load a compiled keymap from /etc/console-setup/; that cached map may still contain the original US configuration. If reboot still restores US, please post what you get with these:
Quotesystemctl status keyboard-setup.service --no-pager --full
systemctl is-enabled keyboard-setup.service
journalctl -b -u keyboard-setup.service --no-pager
ls -l /etc/console-setup/cached*
grep -E 'loadkeys|cached_.*kmap' \
/etc/console-setup/cached_setup_keyboard.sh 2>/dev/null
#3
A20 / Persistent keymap doesn't work
Last post by oly - October 07, 2026, 09:10:25 PMHello,
I use the last A20-OLinuXino-bookworm-minimal-20260323-113959.img on a fresh new SD card with a LIME2.
By default, on system start, the keyboard seems to be mapped with US (or GB).
I use a french keyboard so I tried to set the correct keymap and locales.
No problem with locales but I didn't achieve to get persistent FR AZERTY keymap.
The /etc/default/keymapkeyboard seems correct :
I tried many things from https://wiki.debian.org/Keyboard :
https://wiki.debian.org/Keyboard#Basic_keyboard_configuration_.28Kernel_and_X.29 => no change, still US before and after reboot.
https://wiki.debian.org/Keyboard#Manual_configuration_of_keyboard => no change, still US, still US before and after reboot.
https://wiki.debian.org/Keyboard#How_to_set_keyboard_layout_in_initramfs => no change, still US before and after reboot.
https://wiki.debian.org/Keyboard#How_to_dynamically_activate_Linux_console_settings => changed to FR but not persistent. Go back to US after reboot, as supposed.
Any idea or help welcomed
I use the last A20-OLinuXino-bookworm-minimal-20260323-113959.img on a fresh new SD card with a LIME2.
By default, on system start, the keyboard seems to be mapped with US (or GB).
I use a french keyboard so I tried to set the correct keymap and locales.
No problem with locales but I didn't achieve to get persistent FR AZERTY keymap.
The /etc/default/
Code Select
# KEYBOARD CONFIGURATION FILE
# Consult the keyboard(5) manual page.
XKBMODEL="pc105"
XKBLAYOUT="fr"
XKBVARIANT="azerty"
BACKSPACE="guess"
XKBOPTIONS="terminate:ctrl_alt_bksp"
I tried many things from https://wiki.debian.org/Keyboard :
https://wiki.debian.org/Keyboard#Basic_keyboard_configuration_.28Kernel_and_X.29 => no change, still US before and after reboot.
https://wiki.debian.org/Keyboard#Manual_configuration_of_keyboard => no change, still US, still US before and after reboot.
https://wiki.debian.org/Keyboard#How_to_set_keyboard_layout_in_initramfs => no change, still US before and after reboot.
https://wiki.debian.org/Keyboard#How_to_dynamically_activate_Linux_console_settings => changed to FR but not persistent. Go back to US after reboot, as supposed.
Any idea or help welcomed
#4
ESP32 / BOX-ESP32-P4-PC – 3D/CAD files...
Last post by UfkuAcik - October 04, 2026, 03:17:19 AMHi,
Are there any plans to release the 3D/CAD files for the BOX-ESP32-P4-PC enclosure?
https://www.olimex.com/Products/IoT/ESP32-P4/BOX-ESP32-P4-PC/
STEP or STL files would be especially useful for designing custom mounts, modifications, and project integrations.
I also contacted Olimex support about this previously but did not receive a reply, so I wanted to ask here as well.
If the files already exist somewhere, could you please share the link?
Thanks!
Are there any plans to release the 3D/CAD files for the BOX-ESP32-P4-PC enclosure?
https://www.olimex.com/Products/IoT/ESP32-P4/BOX-ESP32-P4-PC/
STEP or STL files would be especially useful for designing custom mounts, modifications, and project integrations.
I also contacted Olimex support about this previously but did not receive a reply, so I wanted to ask here as well.
If the files already exist somewhere, could you please share the link?
Thanks!
#5
ESP32 / Re: Questions about the PWR-SW...
Last post by LubOlimex - September 28, 2026, 11:24:43 AM1. You have to check the transformer inrush current and what the halogen can draw. For occasional or moderate operation I would expect this load to be reasonable, but we cannot guarantee relay life for frequent photographic-timer switching without measuring the actual inrush and testing the combination.
2. The relay manufacturer specifies:
- Switch-on/operate time: maximum 20 ms
- Switch-off/release time: maximum 10 ms
3. You are correct, typically you can directly control the PWR-SWITCH via 3.3V GPIO but the minimum guaranteed for ESP32 chip is 2.64V so this might be a problem in the worst case scenario. Looking at the schematic tho, and analyzing the optocoupler used, I am more likely to believe the operating range is 2.5V to 5V DC (and not 3V to 5V DC). So my advice is to first test how it goes without a MOSFET, it is very likely it will work just fine.
2. The relay manufacturer specifies:
- Switch-on/operate time: maximum 20 ms
- Switch-off/release time: maximum 10 ms
3. You are correct, typically you can directly control the PWR-SWITCH via 3.3V GPIO but the minimum guaranteed for ESP32 chip is 2.64V so this might be a problem in the worst case scenario. Looking at the schematic tho, and analyzing the optocoupler used, I am more likely to believe the operating range is 2.5V to 5V DC (and not 3V to 5V DC). So my advice is to first test how it goes without a MOSFET, it is very likely it will work just fine.
#6
ESP32 / Questions about the PWR-SWITCH
Last post by RussellFrege - September 26, 2026, 06:21:08 PMI hope, I am in the right forum, I didin't find a better place to put this. I am also not super experienced with electronics.
I'm considering using the PWR-SWITCH with an ESP32 to control a photographic enlarger, and I have a few questions about the current version of the PWR-SWITCH.
1) The manual specifies 16A/3500W for resistive loads and warns about reduced relay life with inductive loads. Would a 110 VA transformer + 100 W halogen lamp be considered a suitable load for frequent switching with the PWR-SWITCH, also considering surge currents? And if not, do you have a suggestion that I could use instead (without high voltage splicing/soldering).
2) Is there any anticipated switching on/off delay, and if yes, how long approximately?
3) Is it OK to just use a GPIO to switch it, or is it safer to use the 5V supply through a MOSFET controlled by the ESP32, since the minimum is specified at 3V and HIGH should be 3.3V is only guaranteed to be 2.64V as far I understand.
Thanks in advance.
I'm considering using the PWR-SWITCH with an ESP32 to control a photographic enlarger, and I have a few questions about the current version of the PWR-SWITCH.
1) The manual specifies 16A/3500W for resistive loads and warns about reduced relay life with inductive loads. Would a 110 VA transformer + 100 W halogen lamp be considered a suitable load for frequent switching with the PWR-SWITCH, also considering surge currents? And if not, do you have a suggestion that I could use instead (without high voltage splicing/soldering).
2) Is there any anticipated switching on/off delay, and if yes, how long approximately?
3) Is it OK to just use a GPIO to switch it, or is it safer to use the 5V supply through a MOSFET controlled by the ESP32, since the minimum is specified at 3V and HIGH should be 3.3V is only guaranteed to be 2.64V as far I understand.
Thanks in advance.
#7
A20 / Re: DEBIAN 13 and up to date k...
Last post by oly - September 23, 2026, 09:15:00 PMI apologize. While my SD card was physically writable, it was not in fact and without warning. I dd the image on another one.
Now it is correct :
Now it is correct :
Code Select
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/" #8
ARDUINO / Re: NB-IoT-BC660H-ANT Rev D — ...
Last post by LubOlimex - September 23, 2026, 09:29:17 AMThis is not very surprising since we just recently switched to revision E of NB-IoT-BC660 boards. Boards from hardware revision E has different print on the PCB that says "NB-IoT-BC660 Rev. E" at the bottom. Based on your description I believe you received the hardware revision D board.
Both revision D and revision E designs use the same main chip BC660K-GL.
Revision D still uses the regulators. Power consumption in deep sleep is the main difference between revisions. The current consumption in deep sleep is minimum around 125uA when powered from external power source and around 85uA when powered from battery. The extra current comes mainly from the AP1231 regulator and two TXB0108 level translators. Aside from that they behave the same. Revision D board is still completely fine.
Comparing revision D to revision B the changes are unnoticeable for the customer (one is not even visible in the schematic). There are only two changes:
1. Revision C:
Changed the the sim card holder with SIMNANO-6P-1.3H, this required some other components to be moved to fit.
2. Revision D:
Updated the module package for better soldering.
My advice for future purchases is to ask beforehand about the hardware revision available.
Both revision D and revision E designs use the same main chip BC660K-GL.
Revision D still uses the regulators. Power consumption in deep sleep is the main difference between revisions. The current consumption in deep sleep is minimum around 125uA when powered from external power source and around 85uA when powered from battery. The extra current comes mainly from the AP1231 regulator and two TXB0108 level translators. Aside from that they behave the same. Revision D board is still completely fine.
Comparing revision D to revision B the changes are unnoticeable for the customer (one is not even visible in the schematic). There are only two changes:
1. Revision C:
Changed the the sim card holder with SIMNANO-6P-1.3H, this required some other components to be moved to fit.
2. Revision D:
Updated the module package for better soldering.
My advice for future purchases is to ask beforehand about the hardware revision available.
#9
ARDUINO / NB-IoT-BC660H-ANT Rev D — powe...
Last post by Dijkmeneer - September 22, 2026, 05:10:05 PMHi all,
I'm posting this in the Arduino section since I found an older thread here about the NB-IoT BC66 module (the "Security mode change issue" thread) where LubOlimex replied — figured this was the closest existing home for NB-IoT-related questions since there doesn't seem to be a dedicated category.
I recently got an NB-IoT-BC660H-ANT board via DigiKey. The PCB silkscreen reads "Rev D," and the module soldered on it is a BC660K-GL (confirmed by reading the chip marking directly). The board also has a populated NETLIGHT LED, and the silkscreen at that pin position is labeled NETLIGHT rather than GPIO6, both of which match BC66's pin function at that position rather than BC660K-GL's. I'm assuming the board layout was carried over unchanged from before the BC66→BC660K-GL module swap (Olimex's blog confirms that transition happened), but I'm curious whether that LED still does anything meaningful with BC660K-GL populated, since that pin is just GPIO6 on this chip rather than a dedicated network-status output.
Separately — the thing I haven't been able to figure out: Olimex's product page FAQ mentions that starting with hardware revision E, the design was optimized for low-power operation by removing a voltage translator and regulator present in older revisions.
Does Rev D already include that optimization, or does it still have the older, higher-current design?
Is there any chance someone could share the Rev D schematic? I've only found Rev B and Rev E published online.
I'm building a battery-powered prototype, so the sleep-current characteristics of my specific board matter for planning battery life.
Thanks in advance for any help!
I'm posting this in the Arduino section since I found an older thread here about the NB-IoT BC66 module (the "Security mode change issue" thread) where LubOlimex replied — figured this was the closest existing home for NB-IoT-related questions since there doesn't seem to be a dedicated category.
I recently got an NB-IoT-BC660H-ANT board via DigiKey. The PCB silkscreen reads "Rev D," and the module soldered on it is a BC660K-GL (confirmed by reading the chip marking directly). The board also has a populated NETLIGHT LED, and the silkscreen at that pin position is labeled NETLIGHT rather than GPIO6, both of which match BC66's pin function at that position rather than BC660K-GL's. I'm assuming the board layout was carried over unchanged from before the BC66→BC660K-GL module swap (Olimex's blog confirms that transition happened), but I'm curious whether that LED still does anything meaningful with BC660K-GL populated, since that pin is just GPIO6 on this chip rather than a dedicated network-status output.
Separately — the thing I haven't been able to figure out: Olimex's product page FAQ mentions that starting with hardware revision E, the design was optimized for low-power operation by removing a voltage translator and regulator present in older revisions.
Does Rev D already include that optimization, or does it still have the older, higher-current design?
Is there any chance someone could share the Rev D schematic? I've only found Rev B and Rev E published online.
I'm building a battery-powered prototype, so the sleep-current characteristics of my specific board matter for planning battery life.
Thanks in advance for any help!
#10
A20 / Re: DEBIAN 13 and up to date k...
Last post by LubOlimex - September 22, 2026, 04:32:13 PMI cannot confirm your findings. I tested both A64-OLinuXino-bookworm-minimal-20260630-091355.img and images and A64-OLinuXino-bookworm-base-20260630-091355.img I get only:
> May be Olimex could maintain two branches of Olimage linux images, one with a fully operational hardware management, one with less proposed peripheral hardware but a more up-to-date OS and kernel versions
You can just run the latest distribution and it will boot, refer to this: https://wiki.debian.org/InstallingDebianOn/Allwinner
I understand the desire for bleeding edge images and so but at the moment this is what we can provide. Unfortunately, not a lot of contribution to our software efforts and we do all the heavy lifting. Of course, our work can be used for free as basis if you wish to build own images.
Code Select
root@a64-olinuxino:~# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
root@a64-olinuxino:~# cat /etc/debian_version
12.14
root@a64-olinuxino:~# ls -l /etc/os-release
lrwxrwxrwx 1 root root 21 May 8 17:15 /etc/os-release -> ../usr/lib/os-release
root@a64-olinuxino:~#
> May be Olimex could maintain two branches of Olimage linux images, one with a fully operational hardware management, one with less proposed peripheral hardware but a more up-to-date OS and kernel versions
You can just run the latest distribution and it will boot, refer to this: https://wiki.debian.org/InstallingDebianOn/Allwinner
I understand the desire for bleeding edge images and so but at the moment this is what we can provide. Unfortunately, not a lot of contribution to our software efforts and we do all the heavy lifting. Of course, our work can be used for free as basis if you wish to build own images.