Перейти к содержанию
    

arhiv6

Свой
  • Постов

    1 033
  • Зарегистрирован

  • Посещение

Сообщения, опубликованные arhiv6


  1. Я бы попробовал добавить пару блокировочных конденсаторов по питанию, по 1000пФ . Там у вас стоят два штуки 180пФ, но с МШУ они по земле соединены не напрямую, а через via.

    image.thumb.png.d061711e0db83e11e244f577ee564ac6.png

  2. Розе использовать не нужно. Для пайки чего-нибудь на керамике, есть специальные низкотемпературные припои, например ПОСК50-18. В ТУ на этот фильтр его тоже указали как один из рекомендованных.

  3. В 20.08.2024 в 13:46, repstosw сказал:

    1) Есть ли смысл убрать аттенюатор с выхода LNA и подобрать резистор на ноге Vbias микросхемы LNA так, чтобы общее требуемое усиление было 9...10 дБ?   При этом ток потребления будет уже не 65 мА, а меньше.   При этом S-параметры поплывут и придётся пересогласовывать вход и выход. Линейность ухудшится?

    Я бы не стал так делать. Линейность ухудшится точно, по шуму проигрыш будет. Лучше просто уменьшите значение аттенюатора до -8.7дБ, чтобы Kp тракта до входа модема стал +12дБ (и эту же настройку выставьте в регистре AGCMAP). Шум тракта получится 1.62дБ.

    В 20.08.2024 в 13:46, repstosw сказал:

    2) В какой программе считаете?

    Программа самописная, RxCalc, скачать можно здесь: https://sourceforge.net/projects/rxcalc/files/  А вообще эти расчёты (RF budget analisys) можно так же делать в ADISimRF , AppCad   и даже простой RFcalc немного умеет.

    В 20.08.2024 в 13:46, repstosw сказал:

    Результат немного отличается

    Третья строка снизу: вы взяли шум от двух компонентов (фильтр+МШУ), а усиление только от МШУ.

  4. В 19.08.2024 в 09:48, repstosw сказал:

    Поэтому на выходе поставил несимметричный П-аттенюатор

    Не совсем понятно, чем симметричный не угодил. Вместо 50/50 Ом по входу/выходу у несимметричного 18.9/53 Ом по входу/выходу.

     

    В 20.08.2024 в 11:49, repstosw сказал:

    Возвращаясь к коэффициенту шума и прочему...     Произвёл расчёты.   Итоговый коэффициент шума, уменьшился почти вдвое (если измерять в разах). Расчёт ниже:

    В блок схеме не учтён аттенюатор. Он (любой пассивный элемента тракта) не просто уменьшает Kp тракта, он так же в тракт добавляет собственный тепловой шум. Т.е. считать нужно не так: 

     

    .thumb.png.8ab242b15c59c7ad2410479da4dce443.png

     

    а вот так:

     

    .thumb.png.d7fb0870caa1d16fdb15d83aa568ffc7.png

     

    Ну и вариант без аттенюатора - Кш лучше почти на 1 дБ (разумеется, в ущерб динамике приёмника):

     

    .thumb.png.48906b3de1014e8a1e9825980b7941f0.png

    • Upvote 1
  5. Не думаю, что для МК есть готовое решение, но его можно собрать из готовых. Если я правильно понял, нужен функционал:

    1) console_shell, т.е. возможность в интерактивном режиме вводить команд (+история, автодополнения). Для МК есть из чего выбрать, например https://github.com/funbiscuit/embedded-cli

    2) tcl_shell, т.е. запуск интерактивного TCL интерпретатора. Прямо на странице сайта TCL есть подборка его легковесных легковесных реализаций. Из подходящего для МК там есть ParTcl (github, статья).

    3) исполнене tcl команд и запуск tcl_shell из console_shell. Это можно сделать так: в составе ParTcl есть интерпретатор, способный сохранять состояние между вызовами. Вот простейший пример как в embedded-cli завести две команды: tcl (вызов интерпретатора и передача ему аргументов команды) и tcl_shell (запуск интерактивного интерпритатора из примера ParTcl). Код:

     

    Спойлер
    #include <stdio.h>
    #include <stdbool.h>
    #include <string.h>
    
    #define TEST
    #include "partcl-master/tcl.c"
    
    #define EMBEDDED_CLI_IMPL
    #include "embedded-cli-master/lib/include/embedded_cli.h"
    
    void writeChar(EmbeddedCli *embeddedCli, char c) { printf("%c",c); }
    
    void tcl_shell_function(EmbeddedCli *cli, char *arg, void *context)
    {
        printf("___partcl shell___\n");
    
        struct tcl *tcl = (struct tcl *)context;
    
        int buflen = 1024;
        char buf[buflen];
        memset(buf, 0, buflen);
        int i = 0;
    
        while (1)
        {
            int inp = getchar();
            if (inp == 0 || inp == EOF) { break; }
    
            buf[i++] = inp;
    
            tcl_each(buf, i, 1)
            {
                if (p.token == TERROR && (p.to - buf) != i)
                {
                    memset(buf, 0, buflen);
                    i = 0;
                    break;
                }
                else if (p.token == TCMD && *(p.from) != '\0')
                {
                    int r = tcl_eval(tcl, buf, strlen(buf));
                    if (r != FERROR)
                    {
                        printf("result> %.*s\n", tcl_length(tcl->result),
                        tcl_string(tcl->result));
                    }
                    else
                    {
                        printf("?!\n");
                    }
    
                    memset(buf, 0, buflen);
                    i = 0;
                    break;
                }
            }
        }
    }
    
    void tcl_cmd_function(EmbeddedCli *cli, char *buf, void *context)
    {
        struct tcl *tcl = (struct tcl *)context;
    
        int i = strlen(buf);
        if (strlen)
        {
            int r = tcl_eval(tcl, buf, i + 1);
            if (r != FERROR)
            {
                printf("result> %.*s\n", tcl_length(tcl->result), tcl_string(tcl->result));
            }
            else
            {
                printf("?!\n");
            }
        }
    }
    
    int main()
    {
        struct tcl tcl;
        tcl_init(&tcl);
    
        EmbeddedCli *cli = embeddedCliNewDefault();
        cli->writeChar = writeChar;
    
        embeddedCliAddBinding(cli, (CliCommandBinding){ .name = "tcl", .tokenizeArgs = false, .binding = tcl_cmd_function, .context = (void *)&tcl });
        embeddedCliAddBinding(cli, (CliCommandBinding){ .name = "tcl_shell", .binding = tcl_shell_function, .context = (void *)&tcl });
    
        printf("___embeddedCli shell___\n");
    
        while (1)
        {
            embeddedCliProcess(cli);
            char ch = getchar();
            embeddedCliReceiveChar(cli, ch);
        }
    
        return 0;
    }

     

     

    Вот что в консоле можно сделать: выполнить две TCL команды из console_shell (присваивание значений переменным), затем запустить интерактивный TCL интерпритатор и в нём выполнить суммирование переменных:

    Цитата

    ___embeddedCli shell___
    > tcl set a 1
    result> 1
    > tcl set b 2
    result> 2
    > tcl_shell
    ___partcl shell___
    puts [+ $a $b]
    3

    result> 3

    • Thanks 1
  6. В 19.07.2024 в 20:28, repstosw сказал:

    Но как было отмечено выше,  не вывозят по затуханию "в пике" -1.5 дБ.  Много.

    А сколько вы хотите? Вот есть такой фильтр -0,73дБ на 440Мгц, на ваших 433МГц у него -1,1дБ. Можете у них же заказать аналог на ваши частоты.

    • Upvote 1
  7. В 19.07.2024 в 14:46, khach сказал:

    Стакан движется по резьбе, выпрессованной на экране.

    Понял, я думал это что-то внутри видно, а это просто внешний корпус вдавлен, тем самым образуя "резьбу". Я до этого видел немного другую конструкцию, где корпус резонатора без этих следов резьбы:

    21711515028744_521.thumb.jpg.fc33f9b01809e2d29f807648e7affa22.jpg21711515028744_846.thumb.jpg.1e0d8f194f017fcbcdaed008380fe59c.jpg

  8. В 13.07.2024 в 22:13, khach сказал:

    Не майтесь дурью - найдите toko 5HT на нужную частоту или на ненужную, но тогда сами перестраивать будете.

    toko BPF.jpg

    5HW_5HT.pdf 47.52 кБ · 39 загрузок

    А есть фото, что внутри у этих фильтров? Если внешний корпус - это резонатор, то как он работает с такими вырезами, через которые видно спираль (или что это там за витки внутри)?

  9. Если полосок залудить - будет хуже. На таких частотах из-за скинэффекта токи почти по поверхности текут, и увеличение толщины за счёт припоя лучше не сделает. А проводимость припоя хуже, чем у меди. Для таких цепей снимают маску и платы с покрытием золотом применяют. Землю - можете лудить, эффекта это не дист никакого.

  10. Добрый день. Как-то выключил управление отображением слоя BOT на одной плате. В "Layers & Colors" значок "глаз" стал серым, на нажатия левой кнопкой мыши не реагирует.  Как его разблокировать? С другими платами проблем нет. Alium 20.2.6.

    image.png.f73cfa903d5d1d2a3c1dacbba3d723de.png

  11. Цитата

    Производитель не рекомендует хранить на SSD файлы звукозаписей, чтобы это не повлияло на качество звука.

    Рано новость выкатили, нужно было до 1 апреля придержать.

  12. Чтобы снимать с солнечной батареи энергию эффективно, не достаточно просто подключить к ней напрямую нагрузку или аккумулятор. Ключевая фраза для поиска "MPPT контроллер". У TI есть готовые микросхемы, которые сочетают в себе как MPPT контроллер, так и контроллер для заряда буферного аккумулятора на одну или несколько ячеек. Вот список, выбирайте подходящий под свои требования (тип аккумулятора, количество ячеек, мощность нагрузки, напряжение солнечной батареи).

    • Like 1
  13. В 06.01.2024 в 19:59, oleg-n сказал:

    Я вижу что подключив один транзистор ко входу модуля ресивера у меня вырасла чувствительность примерно на 10дБ

    Но это не значит, что добавлением МШУ с усилением 50дБ получится изменить чувствительность с -90дБм до -140дБм.

     

    Давайте попробуем посмотреть, как изменится чувствительность приёмника при добавлении двух CMD263P3. Т.к. входных данных слишком мало (не хватает значения ширины полосы приёма (демодуляции) и текущего значения Кш приёмника), попробую поугадывать. Текущая чувствительность -90дБм реализуема при следующих возможных вариантах ПП/Кш: 200МГц/1дБ, 20МГц/11дБ, 2МГц/21дБ, 200кГц/31дБ, 20кГц/41дБ, 2кГц/51дБ, 200Гц/61дБ и т.д. Для первого варианта добавлять МШУ бессмысленно, Кш приёмника только ухудшится (станет 1.41дБ). Для второго варианта и далее чувствительность станет соответственно: -99.44дБм, -109.42дБм, -119.28дБм, -128.09дБм, -132.79дБм, -133.73дБм. Если дальше так же продолжать, всё равно упрётесь примерно в -134дБм, ниже с такими МШУ никак не получить. Вот, я для себя когда-то калькулятор писал https://sourceforge.net/projects/rxcalc/files/RxCalc-0.6.8_installer.exe/download Он помогает оценить динамику, чувствительность приёмника и т.д. Попробуйте сами в нём свой тракт собрать. Вот пример расчёта для варианта 20МГц/11дБ:

     

    image.thumb.png.44e1f11cb20465c5b80c175a091ee457.png   image.thumb.png.ac6e56c299814e13837498ab41b75edc.png

  14. В 31.12.2023 в 19:30, unix сказал:

    Да, пример простейшего диспетчера лет 15 назад DiHalt выкладывал на свое ресурсе.

    Это обычный планировщик задач, где каждая задача это run-to-complete функция, которая вызывается по какому-то событию. Сам когда-то подобный использовал и знаю как минимум одну ОС, которая работает с таким типом задач (uSmartX). Из плюсов такого подхода - минимальное потребление ресурсов и лёгкость портирования (никакого знания ассемблера не требуется). Из минусов - подходит только для простых задач: как только в задаче потребуется после какого-то события (даже обычный вызов delay()) не перезапускать задачу заново, а продолжать выполнять какую-то её логику, то задачи привычнее и проще для понимания писать в непрерывном стиле, как это делается на "взрослых" ОС. Как пример, что проще для понимания, псевдокод задачи из run-to-complete планировщика:

    void task_blink()
    {
        static uint8 led_state = 0;
      
        if (led_state == 1)
        {
            led_off();
            led_state = 0;      
            task_restart(task_blink, 500);
        }
        else
        {
            led_on();
            led_state = 1;
            task_restart(task_blink, 100);
        }  
    }

    или привычный линейный код:

    void task_blink()
    {
        while(1)
        {
            led_on();
            delay_ms(100);
            led_off();
            delay_ms(500);
        }
    }

    И там и там обычное мигание светодиода на 100мс с паузой 500мс, но второй код гораздо проще для понимания. Язык Си позволяет такое реализовать на основе Duff's device. При этом остаются те же достоинства планировщиков (минимальные ресурсы, общий стек, лёгкость портирования из-за отсутствия ассемблера) но разработка задач упрощается. Поэтому есть несколько кооперативных ОС, построенных на этом принципе: cocoOS, DemOS (+ protothreads как самая упрощённая, но рабочая реализация). ТС, если поймёте, что своего диспетчера вам уже недостаточно, но есть какие-то опасения для перехода на FreeRTOS, рекомендую их попробовать. С ростом сложности ваших проектов если упрётесь в их ограничения тогда уже осознанно перейдёте на вытесняющую ОС с раздельными стеками для каждой задачи, но уже с минимальными переделками своего кода.

  15. Сначала берётся с запасом, потом реальное использование памяти каждой задачей можно уточнить (параметр usStackHighWaterMark из структуры TaskStatus_t, которую можно получить из vTaskGetInfo()). Вот статья про это: https://habr.com/ru/articles/352782/ там пятый раздел "Мониторинг использования ресурсов". Кроме того, есть варианты ОС без выделения отдельных стеков для каждой задачи: начиная от protothreads и их производных, заканчивая теми же Co-Routine из состава FreeRTOS.

  16. В 29.12.2023 в 02:48, fpga_student сказал:

    я решил наконец-то навести полный порядок, и натравил на все исходники любимый notepad++, которым сделал примерно 5000 замен скобок.

    Зачем такое делать вручную, если специально для этого существуют стилизаторы кода? Попробуйте Astyle, он очень простой в использовании. Выберите готовый стиль, похожий на свой (что-то вроде --style=kr ), потом при желании можно под себя его донастроить. Уверен, для notepad++ есть плагины для работы с astyle. Но даже если нету - то можно простой макрос сделать, который будет вызывать astyle для текущего файла по какому-нибудь сочетанию клавиш.

×
×
  • Создать...