Valdir Tech

opa, cortei a trilha da antena PCB e soldei um fio direto.. sinal melhorou bem.. agora devo testar a distância máxima em que meu decoder RX consegue ler o sinal do TX

@aphawk opa tocou num ponto que creio que tenhamos que calcular aqui. (1) impedância + SWR (não só seguir os indutores e capacitores sugeridos no datasheet do SYN531)... (2) plano terra... e (3) testes e + testes

@.if obrigado pelo feedback... para contextualizar, não fiz exatamente igual porque: - (1) a fábrica que montará as placas tem preferência de 0806; - (2) pelo q pesquisei os pontos que eu teria que seguir primordiais seriam: - (2.1) tamanho da antena (17,3cm para 433Mhz), considerando este comprimento após o 90º (foto1).... O circuito copiei deste manual do SYN531 (https://datasheet.lcsc.com/szlcsc/1811141751_Synoxo-SYN531R_C77785.pdf) - (2.2) não fiz plano terra abaixo, então não sei se perdi algum ganho direcional com isso pra tentar ganhar omni-direcional;

Tenho um projeto que consigo por volta de 50m com os módulos rxb18 (foto1), mas quando fiz nova placa com os componentes soldados (foto2) consigo somente 25m. Sabem dizer o que preciso melhorar na placa?

Boa Srs. @.if , @Sérgio Lembo Grato pelo grande auxílio.. Somente aproveitando: existe um push pull que recomendam para novo design desta placa?... a aplicação é para controle de luminária RGB 12V 9W.... então tenho um destes mosfets pra cada cor (R, G e B) Detalhe: é um projeto sensível a custo, então creio que não consiga usar algo direto como IR44273 que sai R$2,15 cada o micro que estou usando é STM32F030C6

@.if certo, sei que posso encontrar vários mosfets compatíveis com minha aplicação, mas o fato é que tenho muito deste PJW7N06A em estoque e gostaria que o circuito funcionasse bem com este também @Sérgio Lembo grato pela acertiva... ja testei com resistores menores, até mesmo com jumper direto, já aumentei a frequência de PWM para 10kHz (antes era 2,5)... mas ainda aquece... creio que por conta da VGSth estar no limiar mesmo... Minha dúvida é: será que não acho mosfet P e N capazes de "somente" substituir os transistores e fazer um push-pull capaz de elevar o VGSth do gate ? O sinal do controle pode ser mantido em 0-3v3 @2,5kHz ?

@.if @Sérgio Lembo @rmlazzari58 boas opções sim, muito obrigado. no entanto. eu precisaria de opções de mosfets para somente substituir estes transistores SOT23 porque ja tenho placas prontas. Detalhe: com este BUK9880 funciona porque o VGSth dele é 2V... Hoje tenho somente PJW7N06A, que é 2.5 e esquenta bastante!

Boa tarde, Fiz o seguinte gate driver (foto) usando transistores, achando que iria ter entre 0-10V no gate usando 0-3v3 no controle, mas não tem. Pelas minhas pesquisas, este totem pole pode virar um push-pull se eu substituir os transitores por mosfets P (na fonte) e N (no GND). Gostaria de saber, ao substituir por mosfets, qual mosfets utilizar do mesmo encapsulamento destes BC807/817. Considerando que meu controle PWM é 0-3v3.

São muitas opções que aparecem, tais como PATOLA e até empresas que fazem serviço customizado. Mas o fato é que tenho um projeto de PCB pronto e gostaria de saber se existe alguma padrão, com furação, por exemplo, de entrada de alimentação, botões chave táctil, conector micro-fit, etc... ou eu não tenho saída e preciso mandar customizar para fazer um produto?

@dwatashi Obrigado, mas não creio se tratar do mesmo pacote pois de fato o rastreador manda uma mensagem e depois de 2s (no máximo) manda outra (dá pra ver por um contador de pacotes no final da string)... mas quando é recebido no wireshark, parecem uma... Agora estou investigando esta flag "don't fragment" pois a que o wireshark concatena aparece como '1' e os outros pacotes normais, em '0'.

Boa noite, prezados. Estou testando um rastreador em que configuro a periodicidade de envios de dados para um servidor. e Estou emulando um servidor na minha máquina usando Hercules, por exemplo. Por vezes, o tracker envia dados de eventos em seguida de dados periódicos, e pode ter uma diferença de 2s entre os dados enviados via GPRS / TCP. Vendo no wireshark, alguns pacotes parecem estar sendo recebidos na porta como se fossem um só. Qual seria o motivo desta "concatenação" ??

Prezados, preciso fazer um buffer circular em sistemas de arquivo (usando os comandos fopen,fwrite, etc) cujas mensagens gravadas em determinado arquivo possuem uma sintaxe de "[...]" sendo '[' o Start Of Frame e ']' o End Of Frame, como na imagem abaixo... Hoje estou tentando prosseguir na estratégia da seguinte forma: 1. ao chegar novas mensagens e considerando o arquivo de log já cheio (no meu caso, 30kB): 2. copio as mensagens do OldBuffer para um NewBuffer retirando a mensagem mais antiga; 3. A mensagem que acaba de chegar eu escrevo no final deste NewBuffer; 4. Sempre no próximo looping, quando se chega novas mensagens então, faço esta sequencia. Sugestões?

@.if Boa, eu havia visto este snuber em motores AC, tipo de máquina de lavar, mas vale estudar o uso desta proteção também, obrigado... usando um diodo mais potente, 3A/1000V resolveu em partes o aquecimento... aquece menos do que o de 1A, provavel que tenha algum ruído ainda a ser atenuado... grato pelo suporte Srs

Boa tarde, Prezados, Montei um circuito para controle de velocidade do motor de parabrisa e funciona, mas o diodo que protege contra a Força-Contra-Eletro-Motriz do motor está esquentando... Estou usando um M7 (equivalente ao 1N4007)... Frequência de PWM em 1kHz (tentei reduzir também na casa dos 500Hz mas ainda esquenta). Alguma ideia?

Acabei constatando que era problema no HW. Possivelmente um curto de solfa abaixo do micro SMD que tirando-o, limpando a placa e colocando ele novamente, funcionou. Agora com os 10k. Tks

@vtrx Segue abaixo o que foi feito: @.if obrigado, vou considerar os 10k para teste e validação: Inicialização da ADC_IN0 via STM32CubeIDE: O código gerado por este HAL fica assim: static void MX_ADC_Init(void) { /* USER CODE BEGIN ADC_Init 0 */ /* USER CODE END ADC_Init 0 */ ADC_ChannelConfTypeDef sConfig = {0}; /* USER CODE BEGIN ADC_Init 1 */ /* USER CODE END ADC_Init 1 */ /** Configure the global features of the ADC (Clock, Resolution, Data Alignment and number of conversion) */ hadc.Instance = ADC1; hadc.Init.ClockPrescaler = ADC_CLOCK_ASYNC_DIV1; hadc.Init.Resolution = ADC_RESOLUTION_12B; hadc.Init.DataAlign = ADC_DATAALIGN_RIGHT; hadc.Init.ScanConvMode = ADC_SCAN_DIRECTION_FORWARD; hadc.Init.EOCSelection = ADC_EOC_SINGLE_CONV; hadc.Init.LowPowerAutoWait = DISABLE; hadc.Init.LowPowerAutoPowerOff = DISABLE; hadc.Init.ContinuousConvMode = DISABLE; hadc.Init.DiscontinuousConvMode = DISABLE; hadc.Init.ExternalTrigConv = ADC_SOFTWARE_START; hadc.Init.ExternalTrigConvEdge = ADC_EXTERNALTRIGCONVEDGE_NONE; hadc.Init.DMAContinuousRequests = DISABLE; hadc.Init.Overrun = ADC_OVR_DATA_PRESERVED; if (HAL_ADC_Init(&hadc) != HAL_OK) { Error_Handler(); } /** Configure for the selected ADC regular channel to be converted. */ sConfig.Channel = ADC_CHANNEL_0; sConfig.Rank = ADC_RANK_CHANNEL_NUMBER; sConfig.SamplingTime = ADC_SAMPLETIME_1CYCLE_5; if (HAL_ADC_ConfigChannel(&hadc, &sConfig) != HAL_OK) { Error_Handler(); } /* USER CODE BEGIN ADC_Init 2 */ /* USER CODE END ADC_Init 2 */ } No while(1), está assim: hadc.Instance->CHSELR |= ADC_CHSELR_CHANNEL(ADC_CHANNEL_0); HAL_ADC_Start(&hadc); HAL_ADC_PollForConversion(&hadc,10); value_adc=HAL_ADC_GetValue(&hadc); O código rodando, o valor de value_adc fica assim: Apertando qualquer botão, a variável é zerada:

Prezados, estou tentando ler uma gama de botões via ADC (por conta de limitação de pinos que tenho na placa), assim, usando 1 pinos ADC para ler 5 botões. Consigo ler o pull-up, mas quando aperto o botão, o valor lido é 0 e não o resultado de um divisor de tensão. Segue esta parte do esquemático:

Tenho um código em C para gravar em SoC Mediatek. Trabalho nas libs de aplicação e o low-level (stack TCP, GPS, e RTOS) não são acessíveis. Somente tenho acesso as funções de aplicação mesmo (tipo um Hardware Abstration Layer). Meu código, porém, chegou num nível que está dando bug quando atualizo o device Mediatek via FOTA e tudo me leva a crer que o tamanho código é o responsável por este bug. Minha dúvida é se tem algo a fazer no compilador que possa me ajudar a reduzir. Hoje ja uso a seguinte config no arquivo makefile: CFLAGS = --cpu ARM7EJ-S --littleend -O3 --remove_unneeded_entities --fpmode=fast --split_sections --diag_suppress 1,1295,1296,2548 --dwarf2 --debug --no_debug_macros

entendido sobre o driver "dedicado" para chavear 12v e outro para GND. Pensando num circuito com 2 Low-Sides (para estes 2 mosfets) e mais 2 High-Sides para outros 2 mosfets... Será que não vale mais a pena então usar 2-N e outros 2-P para reduzir em BOM? Este circuito abaixo peguei de outro tópico e me parece simples e funcional... 2-Ps ja tem +12V, bastaria chavear +12V (com driver) noutros 2-Ns

Prezados, estou controlando o sentido e velocidade de um motor 12V 46W com o seguinte esquema (imagem anexa). Quando o motor gira pra um lado, esquenta mais o Q4 e para o outro esquenta o Q2. Minha dúvida é se este esquema de ligar o GATE na mesma trilha pode estar influenciando este mau funcionamento. Estou tentando tratar o ruído com capacitores e ver se o funcionamento fica mais limpo e sem ruído. cada um destes GATES estão sendo chaveados por PWM a 2k5Hz com os drivers IR44273 (imagem) e vou reduzir a freq para teste também.