Некоторое время назад мы познакомились со схемой коммутации НЧ сигналов на полевых МОП-транзисторах. То же самое можно сделать и на JFET. Последний вариант часто встречается в радиолюбительской литературе. Схема простая, но разобраться в ней не повредит.

Стрелочные измерительные головки часто используются в радиолюбительском деле. Например, в самодельном приемнике или трансивере хочется иметь S-метр, а в каком-нибудь согласующем устройстве — индикатор мощности и КСВ. Только достать готовые и красивые головки для подобных задач не так-то просто. Зато можно модифицировать головку, предназначенную для чего-то другого.

Тут по работе возникла задачка с PostgreSQL. Нужно было определить, как часто при определенных условиях вызываются такие-то процедуры, и что они при этом возвращают. Трейсить предстояло совсем чуть-чуть, да и не в проде, поэтому я воспользовался LLDB. Несмотря на то, что это не инструмент трассировки, в моем случае с задачей он справился. И тут я вспомнил, что еще не так давно читал про bpftrace. Хотя, конечно же, успел напрочь все позабыть. Было решено проверить, насколько лучше или хуже bpftrace подошел бы для той же задачи.

Мне нравится работать в телеграфе с QRP-мощностью. Однако имеющиеся у меня трансиверы промышленного производства плохо подходят для этой задачи. Что же до моих самодельных трансиверов, то на данном этапе они далеки от идеала. Особенно большая проблема — это сделать приемник на все КВ-диапазоны без пораженных частот. А с комфортом поработать в эфире хочется. Так вот, недавно мне предоставилась возможность приобрести б/у трансивер Elecraft KX3, который, судя по обзорам, должен хорошо подходить для QRP CW. Было решено воспользоваться этой возможностью.

Ранее в этом блоге приводилось несколько схем УМ для КВ: первый, второй, третий и далее по ссылкам. Изготовление УМ для УКВ на дискретных компонентах тоже возможно. Однако проще и дешевле воспользоваться уже готовым УМ, коих существует в избытке. Одним из таких готовых УМ является Mitsubishi M68776.

Недавно мы разобрались, как PostgreSQL хранит данные на диске. Но как убедиться, что СУБД именно так и работает? Вдруг мы что-то упустили или недопоняли? Можно прочитать данные с диска с помощью утилиты hexdump и посмотреть, что там реально записано. Но это трудоемко, ведь все битики придется декодировать вручную. К счастью, с PostgreSQL идет расширение pageinspect, которое может декодировать битики за нас.

Иногда хочется сделать что-то простое. Но в то же время что-то полезное, чем потом будешь пользоваться. В идеале — радиолюбительский КВ-трансивер. Затрудняюсь сказать, как часто такие желания возникают у нормальных людей, но со мной бывает.

Хотелось бы продолжить тему хороших телеграфных ключей, которые не стоят, как новый трансивер. В прошлый раз мы познакомились с однорычажным манипулятором от Дмитрия, EW4IDP. Казалось бы, ключ обладает оптимальным отношением цена/качество и конкурировать с ним не представляется возможным. Однако не стоит недооценивать китайских производителей.

Ранее мы познакомились со схемами одинарного балансного диодного смесителя и двойного балансного диодного смесителя. Оказывается, что существует еще и тройной балансный смеситель. Рассмотрим же его схему, а также попытаемся понять сильные и слабые стороны этого смесителя.

Недавно мы научились напрямую работать с таблицами PostgreSQL из расширений на C. Предлагаю капнуть чуть глубже и разобраться, как PostgreSQL физически хранит данные на диске. Стоит сказать, что представленный материал не претендует на новизну. Вопрос этот хорошо описан в более чем в одном источнике, не исключая официальной документации на PostgreSQL. Однако мне хотелось бы иметь собственную шпаргалку, акцентирующую внимание на наиболее интересных мне лично моментах.