Hi Kiste,
The case works !!!
What if I checked something hundreds of times and didn't see this miss?
“Thank you” is meager but sincere.
I'm going to look at the other clues at my leisure.
thanks again and regards
Hans
Op dinsdag 5 april 2022 om 18:44:46 UTC+2 schreef Kiste:
> Here's how I would send the data. I didn't compile it, may have errors.
> Also, I'm not sure if the protocol is right, just take it as an example:
>
> var byte HALT_kamer_array[19] =
> {17,218,39,0,0,64,40,0,160,0,0,0,0,0,0,197,66,0,33}
> var byte HEAT_kamer_array[19] =
> {17,218,39,0,0,65,40,0,160,0,0,0,0,0,0,197,2,0,226}
>
> var byte*19 HALT_kamer_long at HALT_kamer_array --these variables are
> very long and
> var byte*19 HEAT_kamer_long at HEAT_kamer_array --cover the existing
> arrays
>
> var byte HALT_hal_array[19] =
> {17,218,39,0,0,64,40,0,160,0,0,0,0,0,0,197,66,0,33}
> var byte HEAT_hal_array[19] =
> {17,218,39,0,0,65,40,0,160,0,0,0,0,0,0,197,2,0,226}
>
> var byte*19 HALT_kamer_long at HALT_hal_array
> var byte*19 HEAT_kamer_long at HEAT_hal_array
>
> var byte*19 send_buffer_long
> var bit send_buffer_next_bit at send_buffer_long:0
>
>
> -- choose what to send
>
> send_buffer_long=HEAT_hal_long -- all the variable is copied to the
> output buffer
>
> -- now send all the bits
>
> LED=on
> _usec_delay(10000) -- send a long burst to calibrate the receiver
> LED=off
> _usec_delay(2000)
>
> for (8*19) loop
>
> LED=on
> _usec_delay(450) -- send a burst
> LED=off
>
> if send_buffer_next_bit == 1 then -- wait additional time if sending a
> "1"
> _usec_delay(840) -- the difference between 1190 and 350
> end if
>
> _usec_delay(350) --you can reduce this a bit to compensate for the
> --time needed for the shifting
>
> send_buffer_long=send_buffer_long >> 1 --takes a while to shift such a
> long
> --variable, but it always takes
> the
> --same amount of time
>
> end loop
>
> LED=on
> _usec_delay(450) -- send a final burst to end the last bit
> LED=off
>
>
> Greets,
> Kiste
>
> Am Dienstag, 5. April 2022, 16:13:19 MESZ hat hans <[email protected]>
> Folgendes geschrieben:
>
>
> Hello Kyle,
> Done but same result
> . PWM1 works and PWM2 not. Now tested on 16F
> How can i combine 19 bytes in one big word
>
> Op dinsdag 5 april 2022 om 13:30:54 UTC+2 schreef Kiste:
>
> Hi hans,
>
> now as I know what it is for, I can give some hints ;-)
>
> I've done remote signals a lot, and I did it this way:
>
> - I keep the PWM running all the time, at 50% duty.
> - I switch the LED on and off by setting the port pin to input/output
> (Works if the LED is directly connected or via bipolar transistor, not via
> FET)
>
> If you're changing the duty cycle to switch the LED on or off, there can
> be a significant delay before the action takes effect. Switching the pin to
> input or output works instantaneous.
>
> In the "procedure hal()" you're calling "command_send_kamer()", which is
> probably wrong?
>
> You've got procedures for sending a bit, a byte and a full command. That
> is good for readability, but not so good for signal quality. You send a
> burst of 450µs, and the following pause codes the bit. If you're at the end
> of a byte, the bit procedure is ended, then the byte procedure is ended,
> then the loop in the command procedure is forwarding one step, the byte
> procedure is called, then the bit procedure is called, and just then
> there's the next burst. That's quite some time passing, which can make a
> "0" look like a "1". Better collect all the bits in a single variable, and
> send all 152 bits in one loop in one procedure.
>
> And even if not, this is using time in bad places:
>
> teller = 0
> for 19 loop
> if x == high then
> command_send_kamer(HEAT_kamer[teller])
> else
> command_send_kamer(HALT_kamer[teller])
> end if
> teller = teller + 1
> end loop
>
> This would be better:
>
> if x == high then
> for 19 using teller loop
> command_send_kamer(HEAT_kamer[teller])
> end loop
> else
> for 19 using teller loop
> command_send_kamer(HALT_kamer[teller])
> end loop
> end if
>
> That way there's no "if" between the bytes.
>
> Greets,
> Kiste
>
>
>
> Am Dienstag, 5. April 2022, 11:47:50 MESZ hat hans <[email protected]>
> Folgendes geschrieben:
>
>
> Everything has its limits. We have tried to make a remote control for his
> two DAIKIN ACs. With PWM1, the case responds just fine with PMW2 not
> responding. The IR LEDs are controlled with an npn. (swapped) . We also
> tried the 16F877a, same result. On an AUDICITY we compared the IR results
> on a TSOP , the IR leds (swapped!)… Both look the same. The frequencies of
> the PMW varied from 35 to 40. No effect.
>
> So that's the end of the story for us and then just fiddling with one PWM,
> which we then switch via hardware. Unless ……. Any of you have a different
> idea.
>
> Attached program and picture
>
> Op maandag 4 april 2022 om 13:52:34 UTC+2 schreef hans:
>
> Thank s Kiste
> . oops, I've now replaced all on/off's with set_dutycycle_percent(..)
> the program that I use works fine with PWM1 but not with PWM2.
> So there must be a difference.
> Where should I look now?
>
> Op maandag 4 april 2022 om 12:04:31 UTC+2 schreef Kiste:
>
> Sorry, no.
>
> PWM2_off() does not set the LED off, it switches off the PWM module and
> passes control of the output pin back to the simple digital output. The
> digital output can be randomly set to "on", you did not set it to "off".
>
> If you want to keep PWM running and switch off the LED, use
>
> pwm2_set_dutycycle_percent(0)
>
> pwm2_on() and pwm2_off() is not switching the *output* to on or off, it
> starts or stops the PWM module. If you want to set LED brightness, you
> don't want to ever stop the module. It's like waiting at the traffic
> lights: You're setting the car speed to zero (=duty_cycle(0)), but you
> don't switch off the engine (=pwm_off()). If the street's going downhill, a
> switched off engine will not surely prevent the car from moving. You need
> to use the right means for the purpose of stopping the car.
>
> Greets,
> Kiste
>
> Am Montag, 4. April 2022, 11:43:01 MESZ hat hans <[email protected]>
> Folgendes geschrieben:
>
>
> Hi Kiste,
> PWM2_off() sets the led ON and PMW2_on () sets the light off..
> regards Hans
>
> Op maandag 4 april 2022 om 09:21:03 UTC+2 schreef Kiste:
>
> Hi hans,
>
> this is what the program should do if the LED is connected to RC1 and GND
> (with resistor):
>
> The LED will slowly light up from off to 99% within one second,
> then it will fade from 99% to 1% within another second.
>
> The LED stays at 1% for half a second
>
> PWM is disabled, so the LED will reflect the port pin, which is undefined
> by default, for half a second
>
> Then, PWM is reactivated and the LED will resume at 1% for 5 seconds,
> before starting over again.
>
> That is not what you're seeing?
>
> Greets,
> Kiste
>
>
>
> Am Sonntag, 3. April 2022, 16:10:38 MESZ hat hans <[email protected]>
> Folgendes geschrieben:
>
>
> A question from a friend. Attached is a test program for the use of the
> second PWM port C1. The results are opposite to the assignment. On is off
> and off is on. See the end of the file, the LED would go on for a long time
> but then it is just off
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jallib/0fc3bf61-ee5b-435f-a883-fbe7e1f9188fn%40googlegroups.com
>
> <https://groups.google.com/d/msgid/jallib/0fc3bf61-ee5b-435f-a883-fbe7e1f9188fn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
>
> https://groups.google.com/d/msgid/jallib/977fd495-4f9e-40f7-b9eb-caa72e361cd4n%40googlegroups.com
>
> <https://groups.google.com/d/msgid/jallib/977fd495-4f9e-40f7-b9eb-caa72e361cd4n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
>
> https://groups.google.com/d/msgid/jallib/a5691502-ada9-4089-8666-3a0399756e44n%40googlegroups.com
>
> <https://groups.google.com/d/msgid/jallib/a5691502-ada9-4089-8666-3a0399756e44n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "jallib" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
>
> https://groups.google.com/d/msgid/jallib/c3f11c7f-47d8-4eaf-bf6d-34bd4761f886n%40googlegroups.com
>
> <https://groups.google.com/d/msgid/jallib/c3f11c7f-47d8-4eaf-bf6d-34bd4761f886n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups
"jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jallib/62993504-3109-4598-8403-ec920d7d63e9n%40googlegroups.com.
