- Welcome to Olimex Support Forum.
Olimex Support Forum
Recent posts
#51
ESP32 / Re: Demo Code for ESP32-P4-Dev...
Last post by LubOlimex - October 09, 2026, 08:25:30 AMESP32-P4-DevKit seems to be in stock at Digikey USA. You can also purchase it directly form our web-shop, we ship to the US.
#52
ESP32 / Re: Demo Code for ESP32-P4-Dev...
Last post by David Covert - October 09, 2026, 12:26:17 AMCan you share where you purchased it? I can't find it at Mouser or Digikey in the US.
Dave
Dave
#53
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.
#54
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
#55
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
#56
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!
#57
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.
#58
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.
#59
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/" #60
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.