Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TX pin is initialized high after startup #154

Open
Scrath1 opened this issue May 13, 2023 · 1 comment
Open

TX pin is initialized high after startup #154

Scrath1 opened this issue May 13, 2023 · 1 comment

Comments

@Scrath1
Copy link

Scrath1 commented May 13, 2023

Hello,
while viewing the signal of my transmitter using an SDR, I noticed that after startup of the raspberry pi, the TX pin of the transmitter is apparently initialized to high and a continuous signal is being sent.
pi-somfy floating pin

The continuous transmission stops after the first command is manually sent. In my case I used a stop command.

Measuring the transmission pin with a multimeter confirms this. Until the first command is sent, the pin is at ~3.3V and afterwards drops to 0V.

I am using a Raspberry Pi 1 model B.

@arthurdent2095
Copy link

arthurdent2095 commented May 5, 2024

I have always had the same problem and have a scheduled command at 2am to close a blind right after a reboot.

But also, over time I am finding my transmitter boards stop working properly after about a year each. It's as if they drift off frequency slightly, putting a finger on the board makes them work again, but they were fine from new. I think this behaviour with the GPIO does not help extend their life.

If there is no fix yet, this time I am motivated to fix it in case it extends the life of the transmitter.

See Issue 120. You have same issue on Pi 1B ; I have Pi Zero W

Edit: I found a fix here.
https://www.electro-tech-online.com/threads/them-pesky-cheapo-433mhz-transmitters.143245/page-2
By soldering a small capacitor on the back of the board as per the very last post on that thread from doar2d, my transmitter is fixed.

Edit: the first call that I can see in the code for set_mode() is in sendCommand() as opposed to in the initialiser startPIGPIO in operateShutters which just calls pigpio.pi(). I think the set_mode() call needs to be removed from sendCommand, moved into startPIGPIO, and possibly also need to write a 0 in the initialiser. When I have time, I will try this, the problem I have is up until the first send command, my normal remotes don't work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants