2022/3/16

教你怎麼分辨Facebook MarketPlace臉書拍賣詐騙

 那種一次賣很多支手機,都很便宜,你密他就在不同縣市(跟刊登地點不同),這種99%都是詐騙。如果照片又是外國人臉孔或者網美臉,註冊時間在兩年內,那就幾乎100%詐騙了。


其實他們有些是帳號被盜,不見得是帳號擁有者在詐騙,如果匯款又是人頭帳戶的話,根本無從追查,報案只是多跑程序。


我也遇過一個流氓臉拿隻故障手機(一部份區域無法觸控這種很難察覺),說他甚麼都不懂,然後很急著要賣我這種,想必流氓臉也不會退我錢,跟這種人交易也要小心。


都進來了順便參考一下我的拍賣,點我名字就看得到,價可議。


PS5光碟版

EVGA RTX3080 FTW3

真無線藍芽耳機

Airpods


以上全新

2022/3/9

esp6288 刷成 wifi延伸器

 



https://circuitdigest.com/microcontroller-projects/nodemcu-esp8266-wifi-repeater-or-range-extender
照這篇文章做

第一次連SSID是MyAP
密碼沒有
192.168.4.1可以連管理介面
換成自己想要的SSID跟密碼

速度測試就測到3MB多
基本Youtube沒問題
測試遊戲延遲也沒問題


2022/3/2

天線阻抗介紹

一、天線阻抗介紹


  天線輸入端的電壓與電流的比值稱為天線的輸入阻抗,在電學中,常把對電路中電流所起的阻止作用叫做阻抗。阻抗單位為歐姆,常用Z表示,是一個覆數Z= R+i( ωL–1/(ω


  具體說來阻抗可分為兩個部分,電阻(實部)和電抗(虛部)。


  其中電抗又包括容抗和感抗,由電容引起的電流阻止稱為容抗,由電感引起的電流阻止稱為感抗。


  不過,阻抗是天線的一個電氣參數,並不是天線導體上的電阻值,需求用到網絡分析儀才幹看到具體的阻抗值。


  一般VHFUHF(高頻)和微波天線多規劃為50歐姆或75歐姆。


  常見的為50ohm,阻抗匹配保證實現信號或能量從“信號源”到“負載”的有效傳送。Z理想的效果即,輸出和輸入端阻抗均是50ohm。


  然而實踐情況是:源端阻抗不會是50ohm,負載端阻抗也不會是50ohm,這個時候就需求若幹個阻抗匹配電路


  而匹配電路便是由電感和電容所構成,這個時候咱們就需求運用電容和電感來進行阻抗匹配電路調試,以到達RF功能Z優。


  二、影響天線阻抗的要素


  1、天線自身的結構形式和外形尺寸;


  天線自己的形狀能夠改動天線的阻抗。


  2、天線的作業頻率;


  天線的作業頻率,因為同一個天線在不同作業頻率上的阻抗是不一樣的。


  3、天線周圍的環境。


  也便是說相同的天線在相同的作業頻率,當天線周圍環境不一致時,天線的阻抗是會徹底不一樣的。這便是為什麽很多自稱功能很好的內置天線,當咱們買回來用在咱們實踐電子產品里時,發現功能經常非常差甚至根本沒法用。


  這是咱們實踐運用時的天線周圍環境跟這個天線在研制時周圍環境不一致導致的。因此在天線周圍環境比較覆雜的時候,天線是非常必要專門進行針對性定制規劃的,特別是內置天線。


  這3個要素中的任何一個產生變化,天線的輸入阻抗就隨之產生變化,也便是天線的功能產生變化。


  三、阻抗匹配的辦法


  阻抗匹配的辦法主要有兩個,一是改動阻抗力,二是調整傳輸線。


  改動阻抗力便是經過電容、電感與負載的串並聯調整負載阻抗值,以到達源和負載阻抗匹配。


  調整傳輸線是加長源和負載間的間隔,配合電容和電感把阻抗力調整為零。


  此刻信號不會產生發射,能量都能被負載吸收。


  高速PCB布線中,一般把數字信號的走線阻抗規劃為50歐姆。一般規則同軸電纜基帶50歐姆,頻帶75歐姆,對絞線(差分)為85-100歐姆。



自旋轉矩振盪器(spin-torque oscillators;STO)的小型智慧裝置進行採集,並將將無線電頻率轉換為能量,為小型電子產品供電。研究人員如今已成功地使用Wi-Fi波段訊號來採集能量,並以無線方式為發光二極體(LED)和其它小型電子裝置/感測器供電,而無需使用任何電池。

開發版序列埠高速傳輸錯誤問題

 請問要如何用serial port傳180000 bytes 左右的資料?

我使用的board是teensy4.0, ram 有1024KB, 存的下這麼多
但目前傳輸到60000 bytes左右時就會出現問題,會有近10000bytes遺失,但接下來的又能繼續傳輸。我懷疑是serial buffer滿了,所以每傳30000 bytes我就Serial.flush()且delayMicroseconds(20000)。但沒有改善,請問這是因為Serial buffer溢位?又要如何解決呢?

[解決方式]
首先謝謝各位的建議。結果這個問題源自於我PC端接收。
我PC端用的是python的pyserial,在接收時,我把數字先轉成ascii再傳(因為我要傳很多筆,中間用\t隔開,若直接傳byte可能會有誤讀)
具體作法是:第一個進來的int*10+第二個
但我中間打錯,*變成**(次方),由於python資料結構會自動延長,結果傳70進來時變成10^70,電腦端延遲了。修改後就能順利傳資料。
不過在我發現這個bug前,我還是成功傳了數字。用的是Serial.availableForWrite(), 基本上是寫一個while loop,檢查已傳多少byte,沒有傳完就繼續寫。不過要給一點餘裕,比方說Serial.availableForWrite()回傳100 bytes,那下一個迴圈我只寫入50 bytes,這樣最穩。
總而言之,謝謝各位幫忙


為了相容於舊系統,把baud rate 降低到9600以下,打個比較複雜的console 畫面,很容易就會發生,會被serial.write 卡住,其實不太好處理。


去年11月,我有試著降低傳輸速度,看能否研發出好的解決方案,試驗結果是,爛的傳輸線是扶不起的阿斗,程式越改越糟,徒然自找麻煩。螢幕前面是用 ESP32 充當邏輯分析儀,讀取 FPGA 輸出的簡單固定頻率的方波(1:1 duty cycle)


高速的處理器如果跟電腦連,windows下必須用 overlapped 結構處理,否則資料極易 loss, 如果是跟 mac 連,這我就沒經驗了
我在 PC 高速傳輸時會遇到線材太爛,傳輸錯誤率飆高的問題,除了更換纜線之外,我很努力嘗試加強電腦檢測錯誤資料的能力,但程式越寫大,效率就越差




低速的 Arduino 極少有問題,但在高速裝置、設定超過幾百 kbps, 我是遇到「穩的時候大約十幾秒沒問題,但我拿個電源線在旁干擾,很快就出錯,而且出錯後很難回復穩定,要先先停止傳輸數秒,然後再重啟傳輸,這招也不是每次都有效」


1. 改一下baud rate, 因為 baud rate 是由mcu震盪頻率除頻而來, 有些速率不是剛好整除, 導致每個 pulse 寬度有誤差, 連續傳送時, 時間造成的 jitter 會累積, 然後接收端就會解碼錯誤, 所以要找一個可以整除的速率, 甚至可能要改變mcu的震盪頻率, 這個問題在早期8051時代, 使用12Mhz震盪器就會有這個問題, 要使用11.059Mhz才能正確收發. 解決這個問題可以先寫一個程式測試傳送多少byte會有錯誤, 例如傳送資料0,1,2,... 每次加1, 這樣接收端就很容易查出來有問題, 然後就可以知道每隔多久要休息一下才能繼續傳送, 最笨就是每1個byte休息一次. 每傳30000 bytes休息一次並沒有甚麼根據, 只是隨意猜測, 結果一定不對.
2. 發送端用2bit停止位元, 例如N82, 這樣可以拉長byte之間的間隔時間, 接收端依然用N81, 這樣就能抓到每個byte的起始位元脈波
3. 用示波器看波形, 線路阻抗與傳送 baud 不匹配時, 可能自己就會造成震盪干擾, 或者TX訊號串音干擾到RX, 這個在較長線路時容易發生, 有時降低 baud 也能改善
4. buffer問題有分軟體與硬體, 通常現在的uart晶片硬體內建buffer有16~256bytes, 軟體則視宣告而定, 例如可以查看 C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino錄下 HardwareSerial.h 裡面的宣告, 這可以透過計算得知會不會滿, 例如buffer有64 bytes, 用你的baud傳送64 bytes需要多少時間, 你的接收端能否在這段時間回應處理, 若真的只是buffer滿的問題, 可以加上同步方法, 文字資料可以用軟體XON/XOFF同步, 二進位資料只能用硬體CTS/RTS同步


180k 有點操,你的uart 標準只有115200 如果好一點也許可以擴展2-4倍。但是你在看一下protocol 要再吃掉至少20%。uart 並不是甚麼高速傳輸好的東西,另外inband sync要看你的機制。 如果資料量要到連續的同步,dual buffer 或是cycling buffer 也是不可少的機制



目前用 atmel 的 51 系列,因為速度不快,資料量不夠大,甚少發生傳輸錯誤,在高速、大量的情形下,最好是有像古代的 DTR, RTS 功能。我之前做的邏輯分析儀,在阿丟諾的板子跑很順,但其實是資料總量相對於電腦的處理能力小很多,電腦側游刃有餘難出包。但在 ESP32 對電腦開 500kbps, 猛產生中斷逼 ESP32 狂送資料,電腦側開始漏接或數據錯誤,即使重傳也是繼續錯誤 (自訂 CRC 檢查數值異常)..