יום רביעי, 29 ביולי 2026

GPS- פרמטרים באפלקציות מותאמות

 

התמונה היא מאפליקציית GPSTest/GNSS Status, והיא מציגה את מצב קליטת ה-GNSS של הטלפון שלך. אעבור על כל הפרמטרים ומה הם אומרים על איכות הקליטה.

1. GNSS Status: 3D Fix ✅

זהו הפרמטר החשוב ביותר.

3D Fix אומר שהמקלט הצליח לחשב:

  • קו רוחב
  • קו אורך
  • גובה

לשם כך נדרשים בדרך כלל לפחות 4 לוויינים, אך בפועל ככל שיש יותר לוויינים איכות הפתרון משתפרת.

היררכיית המצבים:

  • No Fix – אין מיקום
  • 2D Fix – רק מיקום אופקי
  • 3D Fix – מצוין
  • RTK Fix (בציוד מקצועי) – דיוק של סנטימטרים

2. Accuracy ±7 m

זהו הדיוק שהמקלט מעריך.

המשמעות היא שהמיקום האמיתי נמצא, בהסתברות מסוימת, בתוך מעגל שרדיוסו כ-7 מטר.

הערכה:

Accuracy איכות
<1 m RTK מקצועי
1–3 m מעולה
3–5 m טוב מאוד
5–10 m טוב
10–20 m בינוני
>20 m חלש

7 מטר הוא נתון טוב מאוד לטלפון ללא תיקוני RTK.


3. In View = 27

כלומר:

הטלפון "רואה" 27 לוויינים.

הם יכולים להיות ממספר מערכות:

  • GPS
  • Galileo
  • GLONASS
  • BeiDou
  • QZSS
  • SBAS

ככל שרואים יותר לוויינים:

  • יש יותר אפשרויות לבחור את הטובים ביותר.
  • ניתן לקבל פתרון יציב יותר.

27 הוא מספר גבוה.


4. In Use = 22

זה הנתון החשוב באמת.

22 לוויינים משתתפים בפועל בחישוב המיקום.

הערכה:

In Use איכות
4–6 מינימלי
7–10 סביר
10–15 טוב
15–20 מצוין
20+ מעולה

22 לוויינים בשימוש הוא נתון מצוין.


5. הגרף של עוצמת האות (SNR)

כל עמודה מייצגת לוויין אחד.

המספר למעלה הוא ה-SNR.

לדוגמה:

24

20

19

31

26

22

כאן חשוב להבין:

זו אינה עוצמת השידור של הלוויין.

זו איכות הקליטה שהמקלט מקבל.


מהו SNR?

Signal to Noise Ratio

יחס אות לרעש.

אם:

האות חזק

והרעש קטן

ה-SNR גבוה.

אם:

האות חלש

או שיש הרבה רעש

ה-SNR נמוך.


הערכת SNR

SNR איכות
0–10 כמעט לא שימושי
10–20 חלש
20–30 בינוני
30–40 טוב
40–50 טוב מאוד
מעל 50 מצוין

אצלך:

רוב הלוויינים נמצאים בין:

19–31

כלומר:

קליטה בינונית עד טובה.

אם היית בשטח פתוח לחלוטין, היית מצפה לראות יותר ערכים באזור 35–45.


6. AVG SNR = 22.8

זהו ממוצע כל הלוויינים.

הערכה:

AVG SNR איכות
<15 חלש
15–20 בינוני
20–30 טוב
30–40 טוב מאוד
>40 מצוין

22.8 הוא ערך טוב, אבל יש מקום לשיפור אם תצא לשטח פתוח יותר.


7. צבעי העמודות

האפליקציה צובעת לפי איכות האות:

🟢 ירוק – מצוין

🟡 צהוב – טוב

🟠 כתום – בינוני

🔴 אדום – חלש

אצלך:

רוב הלוויינים צהובים.

לוויין אחד ירוק (31).

אין אדומים.

זה סימן טוב.


8. המספרים בתחתית (01, 02, 04...)

אלה הם מספרי הזיהוי של הלוויינים (PRN/SVID).

לצדם מופיעים סמלים שמציינים מאיזו קבוצת לוויינים הם:

  • ● GPS
  • ▲ Galileo
  • ★ GLONASS
  • ובאפליקציות מסוימות גם סמלים נוספים ל-BeiDou או QZSS.

זה מעיד שהטלפון משתמש במספר קונסטלציות, מה שמשפר את הדיוק והזמינות.


9. Speed = 0

רק אומר שאתה עומד.

אין קשר לאיכות הקליטה.


10. Compass

מציג את כיוון הטלפון.

לא קשור ל-GPS אלא לחיישני המצפן (ולעתים גם לפי תנועה).


הערכה כוללת של התמונה

פרמטר הערכה
3D Fix ⭐⭐⭐⭐⭐ מצוין
Accuracy 7m ⭐⭐⭐⭐ טוב
In View 27 ⭐⭐⭐⭐⭐ מצוין
In Use 22 ⭐⭐⭐⭐⭐ מצוין
AVG SNR 22.8 ⭐⭐⭐ טוב
SNR מקסימלי 31 ⭐⭐⭐ טוב
מספר קונסטלציות ⭐⭐⭐⭐⭐ מצוין

המסקנה: הטלפון שלך קיבל פתרון מיקום איכותי מאוד, בעיקר בזכות 22 לוויינים פעילים. עם זאת, איכות האות (SNR) אינה גבוהה במיוחד, מה שמרמז שסביר שהיית ליד מבנים, בתוך רכב, או באזור עם הסתרה חלקית של השמיים. אם תעמוד בשטח פתוח לגמרי, ייתכן שתראה SNR ממוצע של 30–40 ודיוק של 3–5 מטרים ואף טוב יותר.

נקודה נוספת שכדאי להכיר היא DOP (Dilution of Precision), שאינה מוצגת במסך הזה. זהו אחד המדדים החשובים ביותר לאיכות פתרון ה-GNSS, משום שהוא מתאר את הגיאומטריה של פיזור הלוויינים בשמיים. גם עם 22 לוויינים, אם הם מרוכזים בכיוון אחד, הדיוק יהיה פחות טוב מאשר עם 12 לוויינים שמפוזרים היטב. אם תפתח את מסך ה־Sky Plot או את נתוני ה־DOP באפליקציה, אפשר יהיה להעריך את איכות המיקום בצורה מקצועית עוד יותר.

יום שלישי, 28 ביולי 2026

מכשירי vhf/uhf

 

כשמשווים מכשירי קשר VHF/UHF (ידניים, ניידים או נייחים), חשוב להסתכל על מכלול הפרמטרים ולא רק על הספק השידור. בפועל, איכות המקלט והאנטנה משפיעות פעמים רבות יותר מהספק.

1. תחום תדרים

  • VHF (Very High Frequency): בדרך כלל 136–174 MHz.
    • מתאים יותר לשטחים פתוחים, ים, אזורים כפריים.
    • חודר פחות טוב למבנים.
  • UHF (Ultra High Frequency): בדרך כלל 400–470 MHz (יש גם תחומים אחרים).
    • מתאים לערים, מבנים, קניונים ומפעלים.
    • חודר טוב יותר דרך קירות.

2. הספק שידור (RF Output Power)

ההספק נמדד בוואט (W).

דוגמאות:

  • 0.5W – טווח קצר.
  • 1W – תקשורת בסיסית.
  • 2W – מכשירים קטנים.
  • 5W – רוב מכשירי הקשר הידניים המקצועיים.
  • 10W – מכשירים חזקים יותר.
  • 25–50W – מכשירים לרכב או תחנות בסיס.

חשוב להבין:

  • הכפלת ההספק לא מכפילה את הטווח.
  • כדי להכפיל את הטווח בקירוב, לעיתים נדרש גידול משמעותי בהרבה בהספק, ותנאי השטח חשובים לא פחות.

3. רגישות מקלט (Receiver Sensitivity)

זהו אחד הנתונים החשובים ביותר.

הרגישות מציינת את האות החלש ביותר שהמקלט מסוגל לקלוט.

נמדדת בדרך כלל ב־dBm או במיקרו־וולט (µV).

ערכים אופייניים

רגישות איכות
-108 dBm בינונית
-115 dBm טובה
-118 dBm טובה מאוד
-120 dBm מצוינת
-122 dBm מעולה
-124 dBm נדירה מאוד

ככל שהמספר שלילי יותר (למשל ‎-122 לעומת ‎-115), כך המקלט רגיש יותר.


4. SINAD

רגישות נמדדת לרוב לפי 12 dB SINAD.

SINAD מודד את איכות האודיו לאחר הקליטה.

ברוב היצרנים:

  • 12 dB SINAD הוא התקן.
  • פחות מזה בדרך כלל לא משווים בין מכשירים.

5. Selectivity (בררנות)

יכולת המקלט להפריד בין ערוצים סמוכים.

דוגמה:

  • 60 dB – סביר.
  • 70 dB – טוב.
  • 80 dB – מקצועי.
  • מעל 85 dB – מצוין.

6. Adjacent Channel Rejection

עד כמה המקלט מתעלם מערוץ סמוך חזק.

  • 60 dB – בסיסי.
  • 70 dB – טוב.
  • 80 dB – מצוין.

7. Intermodulation Rejection

יכולת להתמודד עם מספר משדרים חזקים בסביבה.

  • 65 dB – סביר.
  • 75 dB – טוב.
  • 80 dB ומעלה – מקצועי מאוד.

זהו נתון חשוב במיוחד ליד אנטנות סלולר, משדרי FM ואתרי תקשורת.


8. Blocking

יכולת המקלט לא להיסתם כאשר יש משדר חזק בקרבת מקום.

  • 80 dB – טוב.
  • 90 dB – מצוין.
  • מעל 95 dB – איכותי מאוד.

9. Dynamic Range

טווח העוצמות שהמקלט מסוגל להתמודד איתן.

ככל שהטווח רחב יותר:

  • פחות עיוותים.
  • פחות רוויה.
  • פחות חסימות.

10. Audio Output

עוצמת הרמקול.

מקובל:

  • 500 mW
  • 700 mW
  • 1W
  • 2W

רמקול חזק יותר שימושי בסביבה רועשת.


11. יציבות תדר

נמדדת ב־ppm.

  • ±5 ppm – בסיסי.
  • ±2.5 ppm – טוב.
  • ±1 ppm – מקצועי.
  • ±0.5 ppm – מצוין.

12. רוחב ערוץ

  • 25 kHz
  • 20 kHz
  • 12.5 kHz
  • 6.25 kHz

כיום ברוב המערכות עובדים ב־12.5 kHz.


13. קצב סטייה (Deviation)

ב־FM:

  • ±2.5 kHz
  • ±5 kHz

14. צריכת זרם

בשידור:

  • 1–3A במכשיר נייד.
  • 8–12A במכשיר 50W.

בקליטה:

  • 200–500 mA.

מה נחשב למכשיר איכותי?

פרמטר בסיסי טוב מקצועי
רגישות -115 dBm -120 dBm -122 dBm ומטה
Selectivity 60 dB 70 dB 80 dB+
Intermod 65 dB 75 dB 80 dB+
Blocking 80 dB 90 dB 95 dB+
יציבות תדר 5 ppm 2.5 ppm 0.5–1 ppm
הספק 2–5W 5W 25–50W (נייד/בסיס)

מה משפיע באמת על טווח התקשורת?

בסדר החשיבות:

  1. גובה האנטנה – הגורם המשמעותי ביותר.
  2. איכות האנטנה והרווח שלה (Gain).
  3. רגישות המקלט.
  4. עוצמת השידור.
  5. תנאי השטח (קו ראייה, הרים, מבנים, צמחייה).
  6. איכות הכבל והמחברים (במערכות עם אנטנה חיצונית).

מניסיוני, במערכות מקצועיות (כמו מערכות רכבת, ביטחון או תשתיות), מהנדסים נותנים דגש רב לאיכות המקלט, לעמידות בפני הפרעות (Intermodulation, Blocking, Selectivity) ולאיכות מערכת האנטנה, משום שאלו משפיעים יותר על הביצועים בפועל מאשר הגדלת הספק השידור בלבד.


רגישות מקלט (Receiver Sensitivity) היא אחד הפרמטרים החשובים ביותר בכל מערכת RF – מכשירי קשר, SDR, מערכות GPS, Wi-Fi, סלולר ועוד. היא קובעת כמה חלש יכול להיות האות שהמקלט עדיין יצליח לקלוט ולהוציא ממנו מידע שימושי.

מהי רגישות מקלט?

כאשר אות רדיו מגיע לאנטנה, הוא נחלש לאורך הדרך בגלל מרחק, מכשולים והפסדי התפשטות. רגישות המקלט היא העוצמה המינימלית שבה המקלט עדיין מסוגל לפענח את האות בצורה תקינה.

לדוגמה:

  • מקלט עם רגישות -120 dBm יוכל לקלוט אותות חלשים יותר ממקלט עם רגישות -110 dBm.
  • ההפרש של 10 dB משמעותו שהמקלט הראשון מסוגל לעבוד עם אות חלש פי 10.

יחידת המדידה – dBm

עוצמת האות נמדדת ב־dBm, שהיא יחידת הספק ביחס ל־1 מיליוואט.

דוגמאות:

עוצמת אות משמעות
0 dBm 1 mW
-30 dBm אות חזק מאוד
-60 dBm אות חזק
-80 dBm אות טוב
-100 dBm אות חלש
-110 dBm חלש מאוד
-120 dBm קרוב לגבול הקליטה
-130 dBm חלש ביותר

ככל שהמספר שלילי יותר, האות חלש יותר.


למה שני מקלטים מתנהגים אחרת?

נניח שני מכשירים:

מכשיר A

  • רגישות: -117 dBm

מכשיר B

  • רגישות: -123 dBm

אם מגיע אות בעוצמה של -120 dBm:

  • מכשיר A כנראה לא יצליח לפענח אותו.
  • מכשיר B עדיין יקלוט אותו.

זו הסיבה שמכשירים מקצועיים ממשיכים לעבוד גם במרחקים גדולים יותר או בסביבה קשה.


מה קובע את רגישות המקלט?

1. רעש עצמי (Noise Figure – NF)

כל מקלט מייצר רעש פנימי.

ככל שהרעש הפנימי נמוך יותר:

  • אפשר לשמוע אותות חלשים יותר.
  • הרגישות משתפרת.

ערכים אופייניים:

Noise Figure איכות
8 dB בסיסי
5 dB טוב
3 dB מקצועי
1 dB מצוין

2. רוחב הפס (Bandwidth)

ככל שרוחב הפס רחב יותר:

  • נכנס יותר רעש.
  • הרגישות יורדת.

לכן:

  • ערוץ של 12.5 kHz יהיה בדרך כלל רגיש יותר מערוץ של 25 kHz.

3. המגבר הראשון (LNA)

ה־Low Noise Amplifier הוא הרכיב הראשון אחרי האנטנה.

אם הוא איכותי:

  • משפר את יחס האות לרעש.
  • מאפשר קליטת אותות חלשים.

4. הדמודולטור

גם אם האות הגיע, צריך לפענח אותו.

דמודולטור איכותי מסוגל לעבוד ביחס אות־לרעש נמוך יותר.


רגישות לעומת איכות שמע

לפעמים המקלט "שומע" את האות, אבל האודיו מלא ברעש.

לכן היצרנים מודדים רגישות לפי 12 dB SINAD, כלומר הרגישות שבה איכות השמע עדיין נחשבת שימושית.


האם רגישות טובה תמיד מספיקה?

לא.

מקלט יכול להיות רגיש מאוד, אבל אם יש לידו משדרים חזקים:

  • הוא עלול להיכנס לרוויה.
  • להיחסם.
  • לייצר הפרעות בין־ערוציות (Intermodulation).

לכן במערכות מקצועיות בוחנים גם:

  • Selectivity
  • Blocking
  • Intermodulation Rejection

רגישות במכשירי קשר

ערכים אופייניים:

רגישות איכות
-112 dBm בסיסית
-116 dBm טובה
-119 dBm טובה מאוד
-121 dBm מקצועית
-123 dBm מצוינת
-125 dBm נדירה מאוד

דוגמה מעשית

נניח ששוטר או עובד רכבת נמצא באזור מרוחק, והאות שמגיע מהמכשיר שלו הוא -121 dBm.

  • מכשיר עם רגישות -116 dBm לא יצליח לקלוט את השידור באופן אמין.
  • מכשיר עם רגישות -123 dBm עדיין עשוי לקבל את ההודעה בצורה ברורה.

מה חשוב יותר – רגישות או הספק?

אם יש שני מכשירים:

  • מכשיר א': 5W, רגישות -116 dBm
  • מכשיר ב': 5W, רגישות -123 dBm

לרוב, מכשיר ב' יספק ביצועים טובים יותר, במיוחד כאשר האותות חלשים.

לעומת זאת, אם לשני המכשירים אותה רגישות, אבל אחד משדר ב־5W והשני ב־10W, השיפור בטווח יהיה בדרך כלל קטן יותר ממה שרבים מצפים, משום שהטווח מושפע גם מגובה האנטנה, איכות האנטנה, תנאי השטח והפרעות.

אם אתה עוסק גם במערכות SDR או במערכות ניטור RF (כמו בפרויקטים של תקשורת ורכבות), אפשר להעמיק גם בחישוב רצפת הרעש (Noise Floor), מקדם הרעש (Noise Figure), יחס אות־לרעש (SNR) ובאופן שבו מחשבים תאורטית את רגישות המקלט באמצעות המשוואה: Sensitivity = Thermal Noise + Noise Figure + Required SNR. זו הגישה שבה משתמשים גם בתכנון מקלטים מקצועיים.

המשוואה התאורטית לרגישות מקלט היא אחת המשוואות החשובות ביותר בהנדסת RF:

\[ \boxed{\text{Sensitivity (dBm)} = \text{Thermal Noise} + \text{Noise Figure} + \text{Required SNR}} \]

כל אחד משלושת המרכיבים מייצג גורם אחר שמגביל את היכולת של המקלט לקלוט אותות חלשים.


1. Thermal Noise – רעש תרמי

זהו הרעש שנוצר באופן טבעי בכל רכיב אלקטרוני בגלל התנועה האקראית של האלקטרונים.

הוא קיים תמיד, גם אם אין שום שידור באוויר.

הרעש התרמי מחושב לפי:

\[ N = kTB \]

כאשר:

  • k – קבוע בולצמן.
  • T – טמפרטורה בקלווין (בדרך כלל 290K, כ־17°C).
  • B – רוחב הפס (Bandwidth) בהרץ.

ביחידות dBm מקובל להשתמש בקירוב:

\[ \boxed{N=-174+10\log_{10}(B)} \]

כאשר:

  • -174 dBm/Hz הוא רעש תרמי בסיסי בטמפרטורת חדר.
  • B הוא רוחב הפס בהרץ.

דוגמאות

רוחב פס 12.5 kHz:

\[ -174+10\log(12500) \]

-133 dBm

רוחב פס 25 kHz:

-130 dBm

כלומר, כאשר מכפילים את רוחב הפס פי 2, הרעש עולה בכ־3 dB.


2. Noise Figure (NF)

זהו הנתון שמתאר כמה רעש המקלט עצמו מוסיף.

אם למקלט היה NF = 0 dB:

הוא לא היה מוסיף שום רעש.

בפועל אין מקלט כזה.

ערכים אופייניים:

NF איכות
8 dB בסיסי
6 dB סביר
4 dB טוב
3 dB מקצועי
2 dB מצוין
1 dB מעולה

ככל שה-NF נמוך יותר:

✔ אפשר לקלוט אותות חלשים יותר.


3. Required SNR

SNR = Signal to Noise Ratio

יחס אות לרעש.

\[ SNR=\frac{Signal}{Noise} \]

בדציבלים:

\[ SNR(dB)=Signal(dBm)-Noise(dBm) \]

אם האות:

-100 dBm

והרעש:

-110 dBm

אז:

SNR = 10 dB


למה צריך SNR?

גם אם האות נקלט, צריך שהוא יהיה חזק מספיק מעל הרעש כדי שניתן יהיה להבין אותו.

לדוגמה:

FM אנלוגי

צריך בדרך כלל:

10–12 dB

DMR

אפשר לעבוד גם סביב:

5–7 dB

P25

לעיתים:

4–6 dB

מערכות דיגיטליות מתקדמות

יש מערכות שמצליחות גם ב־0 dB ואף פחות, בזכות קידוד ותיקון שגיאות.


דוגמה מלאה

נניח:

רוחב פס:

12.5 kHz

הרעש התרמי:

≈ -133 dBm

Noise Figure:

5 dB

SNR דרוש:

12 dB

נקבל:

Sensitivity

=

-133

5

12

=

-116 dBm

זו בדיוק הרגישות הצפויה של המקלט.


אם נשפר את ה-NF

אותו מקלט:

NF

=

2 dB

Sensitivity

=

-133

2

12

=

-119 dBm

שיפור של 3 dB ברגישות.


משמעות של שיפור 3 dB

3 dB פירושו:

אפשר לקלוט אות חלש פי 2.

6 dB:

פי 4.

10 dB:

פי 10.


איך כל פרמטר משפיע?

פרמטר אם הוא גדל השפעה
רוחב פס גדל יותר רעש, רגישות גרועה יותר
Noise Figure גדל המקלט מוסיף יותר רעש
SNR דרוש גדל צריך אות חזק יותר כדי לפענח
רגישות (dBm) נעשית פחות שלילית (למשל -115 במקום -120) המקלט מסוגל לקלוט רק אותות חזקים יותר

דוגמה השוואתית בין שני מקלטים

פרמטר מקלט A מקלט B
רוחב פס 12.5 kHz 12.5 kHz
רעש תרמי -133 dBm -133 dBm
Noise Figure 5 dB 2 dB
SNR דרוש 12 dB 12 dB
רגישות -116 dBm -119 dBm

למרות שהשיפור הוא "רק" 3 dB, הוא משמעותי מאוד בעולם ה-RF, במיוחד בקליטת אותות חלשים.

המשוואה הזו היא הבסיס לתכנון מקלטים במכשירי קשר, מקלטי GPS, ציוד SDR, מערכות סלולר, תקשורת לוויינית ומכ"ם, והיא מאפשרת למהנדסים להבין האם מגבלת הביצועים נובעת מרוחב הפס, מרעש פנימי של המקלט או מדרישת איכות הקליטה (SNR).


יום ראשון, 26 ביולי 2026

ציוד RF

 בשמחה. להלן הסבר מעשי לכל פריט ברשימה, בהקשר של איש RF ברכבת ישראל העוסק בכיסוי סלולרי, Wi-Fi, תקשורת רכבת, איתור הפרעות ושילוב סנסורים.

ציוד RF

Spectrum Analyzer

מה זה? מכשיר המציג את עוצמת האותות כפונקציה של התדר.

למה משמש?

  • גילוי הפרעות RF
  • זיהוי תדרי שידור לא ידועים
  • מדידת עוצמת אות
  • בדיקת LTE / 5G / Wi-Fi

דוגמה: כאשר נוסעים ברכבת ויש ניתוק Wi-Fi, ניתן לבדוק האם קיימת הפרעה בתדר 2.4GHz או 5GHz.


SDR (Software Defined Radio)

מה זה? מקלט/משדר רדיו הנשלט על ידי תוכנה.

למה משמש?

  • ניטור תדרים
  • הקלטת ספקטרום
  • ניתוח אותות
  • פיתוח מערכות RF

דוגמאות

  • ADALM-PLUTO
  • USRP B205
  • USRP B210

NanoVNA / Site Master

מה זה? מנתח רשת וקטורי (VNA).

למה משמש?

  • בדיקת אנטנות
  • מדידת VSWR
  • מדידת הפסדים בכבלים

דוגמה בדיקת אנטנת Wi-Fi לפני התקנה בתחנת רכבת.


GPS Receiver

מה זה? מקלט GPS מקצועי.

למה משמש?

  • סנכרון זמן
  • תיעוד מיקום המדידה
  • איתור מקור הפרעות

RF Power Meter

מה זה? מודד הספק RF.

למה משמש?

  • בדיקת הספק משדר
  • בדיקת תקינות מגברים

Signal Generator

מה זה? מחולל אותות RF.

למה משמש?

  • סימולציית אות תחנת בסיס
  • בדיקות קליטה
  • כיול ציוד

אנטנות

אנטנת דיסקון (Discone)

מה זה? אנטנה רחבת פס.

יתרון מכסה עשרות MHz עד מספר GHz.

שימוש סריקות ספקטרום כלליות.


Log Periodic

מה זה? אנטנה כיוונית רחבת פס.

שימוש

  • איתור מקורות הפרעה
  • בדיקות כיסוי

Yagi

מה זה? אנטנה כיוונית בעלת רווח גבוה.

שימוש

  • מציאת כיוון מקור שידור
  • הגדלת טווח מדידה

Omni Antenna

מה זה? אנטנה המשדרת וקולטת לכל הכיוונים.

שימוש

  • Wi-Fi
  • LTE
  • BLE

GPS Antenna

אנטנה המתחברת למקלט GPS לצורך קליטה מדויקת יותר.


ציוד רשת ו-Wi-Fi

Wi-Fi Analyzer

מה זה? תוכנה או מכשיר לניתוח רשתות אלחוטיות.

שימוש

  • בדיקת עוצמת קליטה
  • זיהוי ערוצים עמוסים
  • פתרון תקלות

Access Point Wi-Fi 6

מה זה? נקודת גישה אלחוטית.

שימוש

  • בדיקות כיסוי
  • פיילוטים בתחנות ובקרונות

Cisco Industrial Router

מה זה? נתב תעשייתי מוקשח.

שימוש

  • רכבות
  • תחנות
  • חדרי ציוד

Ethernet Tester

שימוש בדיקת תקינות כבלי רשת.


PoE Tester

שימוש בדיקת מתח המועבר על כבל רשת להזנת מצלמות וציוד אלחוטי.


ציוד מדידה

Fluke Multimeter

מודד:

  • מתח
  • זרם
  • התנגדות
  • רציפות

כלי בסיסי לכל טכנאי RF.


Oscilloscope

מה זה? אוסצילוסקופ.

שימוש

  • צפייה באותות חשמליים
  • איתור רעשים ותקלות

VSWR Meter

מה זה? מודד התאמה בין משדר לאנטנה.

שימוש זיהוי אנטנה פגומה או כבל פגום.


Field Strength Meter

מה זה? מודד עוצמת שדה אלקטרומגנטי.

שימוש

  • סקרים אלקטרומגנטיים
  • מיפוי קליטה

כבלים ומתאמים

LMR400

כבל RF איכותי עם הפסדים נמוכים.


RG58

כבל RF נפוץ וזול למרחקים קצרים.


SMA

המחבר הנפוץ ביותר ב-SDR.


N-Type

מחבר RF מקצועי לעבודה חיצונית.


BNC

מחבר נפוץ במכשירי מדידה.


TNC

גרסה עמידה יותר של BNC.


Attenuator

מה זה? מנחת RF.

שימוש להורדת עוצמת אות לפני כניסתו למכשיר מדידה.


RF Splitter

שימוש פיצול אות RF למספר ציודים.


RF Combiner

שימוש איחוד מספר אנטנות או מקורות אות.


DC Block

שימוש חסימת מתח DC והעברת RF בלבד.


ציוד DF (Direction Finding)

SDR רב ערוצי

מספר מקלטים הפועלים יחד למדידת הפרשי מופע.


מערך אנטנות

קבוצת אנטנות המשמשת לחישוב כיוון מקור שידור.


GPS Time Sync

סנכרון מדויק בין תחנות קליטה.


תוכנת DF

מבצעת:

  • חישוב אזימוט
  • טריאנגולציה
  • הצגת מקור השידור על מפה

ציוד IoT ו-BLE

ESP32

כרטיס פיתוח הכולל:

  • Wi-Fi
  • Bluetooth

מתאים לניסויים ופיתוח חיישנים.


BLE Gateway

שער תקשורת לאיסוף נתונים ממשואות Bluetooth.


LoRa Gateway

קליטת חיישנים ארוכי טווח בהספק נמוך.


ZigBee Coordinator

ניהול רשת ZigBee של חיישנים.


ציוד בטיחות

אפוד זוהר

עבודה בשטחי מסילה.


קסדת בטיחות

הגנה באתרי תשתית.


נעלי בטיחות

הגנה מפני פגיעות ציוד כבד.


מכשיר קשר

תקשורת מול מוקד ובקרי תנועה.


פנס ראש

עבודה במנהרות וחדרי ציוד.


תוכנות מקצועיות

SDR++

תוכנת הפעלה וניתוח ל-SDR.


GNU Radio

סביבת פיתוח לעיבוד אותות דיגיטליים.


Wireshark

ניתוח תעבורת רשת.


QGIS

מערכת GIS להצגת נתוני קליטה על מפות.


Kismet

גילוי ומיפוי רשתות Wi-Fi.


Ekahau

תכנון ומדידת כיסוי Wi-Fi מקצועי.


AirMagnet

ניתוח תקלות וקליטה אלחוטית.


MATLAB

ניתוח אותות, DSP ואלגוריתמים.


LabVIEW

פיתוח מערכות בדיקה ואוטומציה.


לפרויקט "מערכות מידע רכבת ישראל" שבו אתה עוסק, הייתי מדרג כציוד הליבה החיוני ביותר:

  1. Spectrum Analyzer
  2. SDR B205/B210
  3. Laptop חזק
  4. אנטנת Discone
  5. Antenna Log Periodic
  6. NanoVNA
  7. Wireshark
  8. Kismet
  9. QGIS
  10. Cisco Industrial Router

אלה יספקו כ־90% מהיכולות הנדרשות למדידות RF, ניטור ספקטרום, Wi-Fi, LTE/5G ובדיקות שטח ברכבת.

ציוד RF - מערכות מידע

 

ציוד RF - מערכות מידע ר

טבלת ציוד מרכזית

מס'פריטתיאורכמותמחיר (₪)
1Spectrum Analyzerספקטרום אנלייזר מקצועי לניטור, גילוי וניתוח תדרים360,000
2ציוד RF + SDRאנטנות, כבלי RF, מנחיתים (Attenuators), מחברים, ציוד SDR ואביזרי RF1 סט30,000
3בקרים וכרטיסי פיתוח BT/WiFiESP32, Arduino, Raspberry Pi, מודולי תקשורת Bluetooth ו-WiFi1 סט10,000
4מחשב עיבוד חזקמחשב ביצועים גבוהים לעיבוד נתוני RF ו-SDR17,500

סיכום תקציבי

קטגוריהסכום (₪)
Spectrum Analyzer60,000
ציוד RF + SDR30,000
בקרים וכרטיסי פיתוח BT/WiFi10,000
מחשב עיבוד חזק7,500
סה"כ פרויקט107,500 ₪

מטרת המערכת

מערכת RF לניטור, איסוף וניתוח אותות אלחוטיים עבור מערכות מידע ברכבת ישראל, הכוללת:

  • ניטור ספקטרום RF
  • קליטת ושידור אותות באמצעות SDR
  • תקשורת WiFi ו-Bluetooth
  • עיבוד וניתוח נתונים בזמן אמת
  • תמיכה בפיתוח והרחבת סנסורים עתידיים

סה"כ תקציב משוער: 107,500 ₪

יום שלישי, 21 ביולי 2026

בדיקת המוצר של חברת אינפודום - נל"א - נגד שיבושי GPS

 קישור למערכת - GPSdome-SunStone - infiniDome



כן, GPSdome-SunStone הוא מוצר שנועד בדיוק למצבים שבהם קיימים שיבושי GNSS/GPS, והוא רלוונטי מאוד לאזורים שבהם קיימת פעילות שיבוש אלקטרונית. לפי היצרן, מדובר במודול Anti-Jamming המתחבר בין אנטנת ה-GNSS לבין המקלט ומבצע סינון ודיכוי של אותות שיבוש תוך שמירה על קליטת אותות הלוויין. [infinidome.com]

הסבר על הפרמטרים העיקריים

Protected Frequency

המערכת מגנה על תחומי GNSS שונים:

  • GPS L1
  • Galileo E1
  • GPS L2
  • GPS L5
  • GLONASS G1

המשמעות היא שההגנה אינה מוגבלת רק לתדר GPS הסטנדרטי, אלא גם למערכות ניווט לווייניות נוספות. [infinidome.com]

Passthrough Frequencies

ניתן להעביר שני תחומי GNSS נוספים לפי בחירת הלקוח, כך שהמערכת מסוגלת לעבוד עם מקלטים מתקדמים התומכים במספר תדרים בו זמנית. [infinidome.com]

Null Steering Algorithm

זהו אחד הפרמטרים החשובים ביותר.

המערכת מזהה את כיוון מקור השיבוש ומנסה ליצור "אפס" (Null) בכיוון זה, תוך שמירה על קליטת הלוויינים בכיוונים אחרים. מדובר בטכנולוגיה נפוצה במערכות Anti-Jam מתקדמות. [infinidome.com]

Insertion Loss

זהו איבוד ההספק שמתווסף כאשר מכניסים את המערכת למסלול האות.

ככל שהערך נמוך יותר, כך פחות אות GPS "נאבד" בדרך.

היצרן לא מפרט בדף המוצר את הערך המספרי. [infinidome.com]

Latency

השהיה קבועה של:

100ns ±15ns

זהו ערך נמוך מאוד שאינו משפיע על רוב יישומי הניווט והתזמון. [infinidome.com]

Power Consumption

צריכת הספק:

פחות מ-2.7W

מתאים למערכות ניידות, רחפנים, רכבים ומתקנים מרוחקים. [infinidome.com]

Retrofit

המערכת תוכננה להתחבר לרוב מקלטי ה-GNSS והאנטנות האקטיביות ללא צורך בשינוי משמעותי במערכת. [infinidome.com]


לגבי שיבושי GPS בישראל

ידוע וקיים תיעוד ציבורי נרחב לכך שבאזור ישראל ובמזרח התיכון קיימים אירועי GNSS Interference מעת לעת, במיוחד בתקופות של מתיחות ביטחונית. גם גופי תעופה בינלאומיים וגם מערכות ניטור אזרחיות מציגים הפרעות GNSS באזור. [flightradar24.com], [faa.gov]

עם זאת:

אין מידע ציבורי אמין ומדויק על עוצמות השידור של מערכות השיבוש הצבאיות.

עוצמת השיבוש בפועל משתנה לפי:

  • סוג המשבש
  • גובה האנטנה
  • המרחק מהמשבש
  • הטופוגרפיה
  • התדר המשובש
  • סוג האנטנה של המקלט

ולכן לא ניתן לקבוע מספר dBm או Watt מייצג לכל הארץ.


האם המערכת תגן על אנטנת GPS בתחנת רכבת?

התשובה היא:

כן, במידה מסוימת ולעיתים בצורה משמעותית, אך לא ב-100%.

תרחיש 1: שיבוש חלש עד בינוני

אם תחנת הרכבת נמצאת עשרות קילומטרים ממקור השיבוש והאות המפריע אינו חזק במיוחד:

✅ סיכוי גבוה שהמערכת תשמור על קליטת GPS.


תרחיש 2: שיבוש כיווני

אם השיבוש מגיע ממקור מסוים בכיוון מוגדר:

✅ טכנולוגיית ה-Null Steering יכולה לשפר מאוד את שרידות הקליטה. [infinidome.com]


תרחיש 3: שיבוש חזק מאוד

אם ליד התחנה נמצא משבש רב עוצמה או שהתחנה נמצאת בתוך "בועת שיבוש":

❌ גם מערכות Anti-Jam יתקשו לשמור על רציפות GPS.

אין כיום מערכת קסם שמבטיחה 100% עבודה מול כל משבש.


האם הייתי מתקין אותה במערכת רכבת?

אם מערכת הרכבת מסתמכת על GPS עבור:

  • סנכרון זמן (Timing)
  • מיקום רכבות
  • מערכות תקשורת
  • מערכות ניטור

אז מדובר בשכבת הגנה מועילה.

אבל במתקן קריטי כגון רכבת הייתי ממליץ בנוסף על:

  1. מקלט GNSS רב-תדרי (L1/L2/L5)
  2. תמיכה ב-GPS + Galileo + GLONASS + BeiDou
  3. מערכת INS (אינרציאלית)
  4. שעון Holdover איכותי (OCXO/Rubidium)
  5. Anti-Jam כגון SunStone

כך שגם אם ה-GPS ייעלם זמנית, המערכת תמשיך לפעול.

לדעתי, עבור תחנת רכבת קבועה, ה-GPSdome-SunStone לבדו אינו פתרון מלא, אך הוא בהחלט יכול להקטין משמעותית את הסיכון מהפרעות GNSS נפוצות ולשפר את שרידות קליטת ה-GPS בתרחישי שיבוש רבים. [infinidome.com], [faa.gov]


בתרחיש שאתה מתאר, חשוב להבין שהמערכת אינה "אנטנת GPS רגילה" אלא למעשה מערכת GPS Re-Radiator:

  1. אנטנת GPS חיצונית על גג התחנה.
  2. כבל קואקסיאלי אל תוך המבנה.
  3. מגבר.
  4. אנטנה פנימית שמקרינה מחדש את אותות ה-GPS בתוך התחנה.

במערכת כזו, נקודת התורפה העיקרית היא האנטנה שעל הגג, משום שהיא זו שקולטת את אותות הלוויין החלשים. אותות GPS שמגיעים מהחלל הם ברמות נמוכות מאוד (בסביבות ‎-130 dBm עד ‎-125 dBm במקלט), ולכן גם שיבוש חלש יחסית יכול לפגוע בקליטה.

האם GPSdome-SunStone יעזור?

אם תחבר את ה-SunStone בין אנטנת הגג לבין הכבל הקואקסיאלי:

אנטנת GPS
     |
GPSdome SunStone
     |
כבל קואקס
     |
מגבר
     |
אנטנה פנימית

המערכת עשויה לשפר משמעותית את עמידות התחנה לשיבושים בזכות מנגנון Anti-Jam ו-Null Steering של היצרן. [infinidome.com]

מתי זה יעבוד טוב?

✅ שיבושים מרוחקים.

✅ שיבוש המגיע מכיוון מוגדר.

✅ שיבוש המיועד לאזור רחב ולא ספציפית לתחנת הרכבת.

✅ הפרעות ממקורות סלולר, משדרים או ציוד RF בקרבת מקום.


מתי זה עלול לא להספיק?

❌ אם קיים משבש חזק מאוד בקרבת התחנה.

❌ אם מקור השיבוש נמצא במרחק של מאות מטרים בודדים.

❌ אם נעשה שימוש במספר משבשים ממספר כיוונים.

❌ אם מדובר ב-Spoofing מתקדם (זיוף אותות GPS ולא רק שיבוש).


מה הייתי ממליץ לתחנת רכבת?

במערכת קריטית של רכבת לא הייתי נשען רק על GPSdome.

הייתי בונה שכבות הגנה:

GPS Roof Antenna
        |
Anti-Jam Unit
        |
GNSS Receiver
        |
Holdover OCXO/Rubidium
        |
Distribution Amplifier
        |
Indoor Re-Radiator

כך גם אם יש הפסד GPS למספר דקות או שעות, מערכת הסנכרון ממשיכה לעבוד.

הערכה מעשית

אם כיום התחנה מאבדת GPS בזמן אירועי שיבוש אזוריים, יש סיכוי טוב ש-SunStone ישפר את המצב בצורה מורגשת.

אם התחנה נמצאת ממש בתוך אזור שיבוש חזק, לא הייתי מצפה ל-100% הגנה. במקרה כזה בדרך כלל מוסיפים:

  • אנטנה כיוונית או אנטנת CRPA.
  • מקלט GNSS רב-תדרי.
  • Anti-Jam.
  • מקור זמן חלופי (OCXO/Rubidium/PTP).

הייתי אומר שלתחנת רכבת טיפוסית בישראל, ה-SunStone הוא שכבת הגנה טובה, אך לא תחליף לתכנון מלא של שרידות GNSS. אם תוכל לציין איזה ציוד GPS מותקן בתחנה (יצרן ודגם המקלט), אוכל להעריך בצורה מדויקת יותר את רמת ההגנה הצפויה.


אם מדובר בתרחיש שאתה מתאר של:

  • Spoofing (זיוף GPS)
  • מספר משדרי שיבוש במקביל
  • עוצמות שידור גבוהות מאוד (עשרות עד מאות ואטים)
  • מוקדי שידור מרובים מסביב לתחנה

אז צריך להיות מציאותיים:

התשובה הקצרה

לא ניתן להניח ש-GPSdome-SunStone לבדו יספק הגנה מלאה בתרחיש כזה. היצרן מציג את המוצר כפתרון Anti-Jam קומפקטי למערכות קטנות, רחפנים, רכבים ופלטפורמות אוטונומיות, אך אינו מציג אותו כמערכת אסטרטגית חסינת כל סוגי השיבוש והזיוף. [infinidome.com], [faa.gov]


במקרה של שיבוש רב עוצמה

אות GPS מהלוויינים מגיע לקרקע חלש מאוד.

כאשר קיימים מספר מקורות שידור חזקים, יחס האות לרעש (J/S) עלול להפוך לגרוע מאוד.

במצב כזה:

Signal GPS
-
Jammer 1
Jammer 2
Jammer 3
Jammer 4

גם אם המערכת מסננת חלק מההפרעות, ייתכן שבשלב מסוים לא יישאר מספיק אות לווייני לשם ניווט או תזמון אמין.


במקרה של Spoofing

Spoofing הוא בדרך כלל איום קשה יותר מ-Jamming.

ב-Jamming המקלט מאבד GPS.

ב-Spoofing המקלט עלול לחשוב שהוא קולט GPS תקין בעוד שהוא למעשה מקבל מיקום או זמן מזויפים. [faa.gov]

אם מטרת מערכת התחנה היא:

  • הפצת GPS לנוסעים
  • אספקת מיקום למכשירים
  • סנכרון זמן

אז Spoofing עלול להיות מסוכן יותר משיבוש רגיל.


מהו החיסרון של Re-Radiator בתחנה?

כאשר אתה מקרין GPS מחדש בתוך התחנה:

GPS Roof Antenna

Receiver

Amplifier

Re-Radiator

כל התחנה תלויה במקור GPS יחיד.

אם המקלט שעל הגג הוטעה:

מקלט GPS ← הוטעה

מגבר

אנטנה פנימית

כל הנוסעים מקבלים GPS שגוי

כלומר, ה-Re-Radiator מפיץ גם את הטעות.


מה עושים במערכות קריטיות?

במערכות קריטיות נהוג להוסיף מספר שכבות:

GNSS Multi Constellation
(GPS + Galileo + Glonass + BeiDou)

+
Anti Jam

+
Anti Spoofing Detection

+
OCXO / Rubidium

+
INS

+
Monitoring System

כך בודקים:

  • האם הזמן קפץ פתאומית.
  • האם המיקום קפץ.
  • האם מספר הלוויינים הגיוני.
  • האם אותות מגיעים מאותו כיוון.
  • האם קיימת סטייה לעומת השעון האטומי.

במקרה של תחנת רכבת

אם התחנה נמצאת באזור שבו יש:

  • שיבושים אזוריים תכופים.
  • Spoofing.
  • מספר משבשים במקביל.

הייתי מדרג את התרומה כך:

רכיבתרומה
SunStone Anti-Jamבינונית עד גבוהה
GNSS רב-תדריגבוהה
Rubidium Holdoverגבוהה מאוד
Anti-Spoofing Receiverגבוהה מאוד
CRPA אנטנה אדפטיבית מקצועיתגבוהה מאוד

המסקנה שלי

לתרחיש של שיבושים אזוריים רגילים, SunStone עשוי לשפר משמעותית את שרידות הקליטה. [infinidome.com]

אבל בתרחיש שאתה מתאר של:

  • Spoofing,
  • מספר מקורות שיבוש,
  • ועוצמות גבוהות,

הייתי רואה בו שכבת הגנה אחת בלבד ולא פתרון מלא. במערכת רכבת שמפיצה GPS לנוסעים ולציוד, פתרון מקצועי יותר יהיה שילוב של מקלט GNSS מתקדם, Anti-Spoofing, שעון Holdover (OCXO או Rubidium) ואמצעי ניטור שיזהו בזמן אמת שהאות שהתקבל אינו אמין, במקום להסתמך על Anti-Jam בלבד. [infinidome.com], [faa.gov]


אם מדובר במערכת רכבת קבועה, העלויות יכולות לנוע מאלפי דולרים בודדים ועד עשרות אלפי דולרים, תלוי ברמת השרידות הנדרשת מול שיבוש ו-Spoofing.

1. Anti-Jam (כגון GPSdome SunStone)

היצרן לא מפרסם מחיר רשמי, אך בשוק מערכות Anti-Jam קומפקטיות מהסוג הזה נמכרות בדרך כלל בטווח של:

  • 2,000 עד 8,000 דולר ליחידה
  • בגרסאות OEM בכמויות גדולות המחיר עשוי להיות נמוך יותר

ה-SunStone מוגדר ע"י היצרן כפתרון "First Layer of Protection" בעיקר מול שיבוש בעוצמה נמוכה עד בינונית. [honeywella...ospace.com], [infinidome.com]


2. מקלט GNSS עם Anti-Spoofing

כאן מתחיל ההבדל הגדול.

רמה בסיסית

u-blox F9P

  • 200-500 דולר

מספק Multi Constellation אך יכולות Anti-Spoofing מוגבלות יחסית.


רמה מקצועית

Septentrio Mosaic-X5

כולל טכנולוגיית AIM+ לזיהוי והקטנת השפעות Jamming ו-Spoofing. [septentrio.com], [shop.septentrio.com]

מחיר המודול עצמו:

כ-567 דולר למודול OEM. [digikey.com]

ערכת פיתוח:

כ-1,195 אירו. [shop.septentrio.com]


רמה תשתיתית / ביטחונית

מקלטים של:

  • Septentrio
  • Trimble
  • NovAtel
  • JAVAD

עשויים להגיע ל:

  • 3,000 עד 15,000 דולר
  • ולעיתים יותר

בהתאם לרישוי וליכולות Anti-Spoofing.


3. OCXO Holdover

OCXO הוא הפתרון המשתלם ביותר לרוב תחנות הרכבת.

טווח מחירים טיפוסי:

  • 500 עד 2,000 דולר

מערכות Time Server עם OCXO מובנה:

היתרון:

  • ממשיך לשמור זמן גם כאשר ה-GPS נופל.
  • עלות נמוכה יחסית.

4. Rubidium

זה כבר "שעון אטומי קטן".

טווח עלויות טיפוסי:

  • 3,000 דולר עד 15,000 דולר

במוצרים צבאיים או תשתיות לאומיות:

  • 20,000 דולר ומעלה

Safran SRO-100 למשל הוא Rubidium Atomic Clock המיועד בדיוק למצב של אובדן GNSS ושמירת זמן רציפה. [safran-group.com], [safran-nav...timing.com]


5. אנטנות CRPA

זה הפתרון החזק ביותר מול שיבושים.

CRPA = Controlled Reception Pattern Antenna

מדובר במערך של 4-8 אנטנות המבצע Null Steering אמיתי.

יכולות:

  • חסימת מספר משבשים במקביל.
  • הפחתת Jamming.
  • שיפור משמעותי בשרידות.

עלות:

  • 15,000 עד 50,000 דולר

מערכות צבאיות:

  • 50,000 עד מאות אלפי דולרים.

6. מערכות Anti-Spoofing אמיתיות

כן, קיימות.

לדוגמה:

  • Septentrio AIM+
  • Trimble ProPoint
  • NovAtel GAJT + OEM7
  • AccuBeat Time Firewall

AccuBeat הישראלית אף מציגה מוצרים ייעודיים לזיהוי Spoofing והגנה על מערכות זמן קריטיות. [accubeat.com]

מחירים טיפוסיים:

  • 5,000 עד 30,000 דולר

למערכת מלאה.


אם זו הייתה תחנת רכבת בישראל

אני הייתי בונה משהו כזה:

GPS/Galileo Antenna
|
GPSdome SunStone
|
Septentrio Receiver
|
Rubidium Holdover
|
Distribution Amplifier
|
Indoor Re-Radiator

עלות משוערת:

רכיבמחיר
אנטנת GNSS מקצועית300-1,500$
SunStone2,000-8,000$
Septentrio1,000-5,000$
Rubidium5,000-15,000$
Distribution Amplifier500-2,000$
התקנה וכבילה1,000-5,000$

סה"כ:

כ-10,000 עד 35,000 דולר לתחנה.


אבל לפי התרחיש שהצגת קודם של מספר מוקדי Spoofing ושיבוש בעוצמות גבוהות מאוד בו-זמנית, אני חושב שהשדרוג המשמעותי ביותר לא יהיה SunStone אלא CRPA + מקלט Septentrio/NovAtel עם Anti-Spoofing + Rubidium. זה כבר פתרון ברמה של תשתית קריטית ולא רק הגנת GPS בסיסית. [infinidome.com], [septentrio.com], [accubeat.com] 

אם המטרה היא להגן על תחנת רכבת מפני שיבושי GPS וספוּפינג, הייתי מחלק את העלויות ל-3 רמות:

רמה 1 – בסיסית

  • אנטנת GNSS איכותית: 300-1,500$
  • GPSdome SunStone: כ-2,000-8,000$
  • מקלט GNSS מקצועי: 500-2,000$

סה"כ: כ-3,000-10,000 דולר. [infinidome.com], [safran-group.com], [thinksrs.com]


רמה 2 – מומלצת לתחנת רכבת

  • GPSdome SunStone
  • מקלט Septentrio עם יכולות Anti-Spoofing
  • OCXO איכותי
  • מגבר הפצה (Distribution Amplifier)

סה"כ: כ-10,000-25,000 דולר. [safran-nav...timing.com], [safran-nav...timing.com], [faa.gov]


רמה 3 – תשתית קריטית

  • אנטנת CRPA נגד שיבוש
  • Anti-Jam מתקדם
  • מקלט Septentrio / NovAtel
  • Rubidium Atomic Clock
  • מערכת Anti-Spoofing ייעודית

סה"כ: כ-30,000-100,000 דולר ואף יותר. [elpromaele...ronics.com], [iqdfrequen...oducts.com], [flightradar24.com]


רכיב בודד של Rubidium

שעון Rubidium מקצועי לתשתיות:


מה הייתי שם בתחנת רכבת בישראל?

אם התקציב סביר והאיום הוא שיבושים אזוריים:

  • SunStone
  • מקלט Septentrio
  • Rubidium

עלות כוללת משוערת:

15,000-30,000 דולר לתחנה (כ-55,000-110,000 ₪).

זה בדרך כלל נותן את יחס העלות-תועלת הטוב ביותר מול שיבושי GPS אזוריים והפרעות תזמון. [safran-nav...timing.com], [timemachinescorp.com], [infinidome.com]

יום רביעי, 17 ביוני 2026

ניסוי פרוייקט עם מחשב רגיל מול טלפון ב BT

 מצוין! 🎉

מהצילום רואים:

✅ Bluetooth מופעל
✅ המחשב משדר בשם:

DESKTOP-LS79N7L

✅ המחשב מוגדר כ־Discoverable (ניתן לגילוי)

צעד 3

עכשיו קח את הטלפון שלך:

  1. פתח הגדרות → Bluetooth

  2. הפעל Bluetooth אם הוא כבוי.

  3. לחץ על סריקה / Search / Pair new device.

חפש ברשימת ההתקנים:

DESKTOP-LS79N7L

שזה שם המחשב שלך.

📱 כתוב לי:

  • האם אתה רואה את DESKTOP-LS79N7L בטלפון?

  • אם כן, לחץ עליו ונסה לבצע Pair (צימוד).

אם מופיע קוד בן 6 ספרות בשני המכשירים, אשר אותו בשניהם.

ברגע שהטלפון יתחבר למחשב, נעבור לשלב הבא שבו נזהה את המחשב מתוך אפליקציה ונעבוד לקראת "תחנת אשקלון".


מצוין! 🎉

מהצילום רואים:

✅ Bluetooth מופעל
✅ המחשב משדר בשם:

DESKTOP-LS79N7L

✅ המחשב מוגדר כ־Discoverable (ניתן לגילוי)

צעד 3

עכשיו קח את הטלפון שלך:

  1. פתח הגדרות → Bluetooth

  2. הפעל Bluetooth אם הוא כבוי.

  3. לחץ על סריקה / Search / Pair new device.

חפש ברשימת ההתקנים:

DESKTOP-LS79N7L

שזה שם המחשב שלך.

📱 כתוב לי:

  • האם אתה רואה את DESKTOP-LS79N7L בטלפון?

  • אם כן, לחץ עליו ונסה לבצע Pair (צימוד).

אם מופיע קוד בן 6 ספרות בשני המכשירים, אשר אותו בשניהם.

ברגע שהטלפון יתחבר למחשב, נעבור לשלב הבא שבו נזהה את המחשב מתוך אפליקציה ונעבוד לקראת "תחנת אשקלון".


מעולה. נתחיל בצורה הכי פשוטה שיש, בלי אפליקציה ובלי הצפנה בשלב זה.

שלב 1 – התקנת אפליקציית סריקת BLE בטלפון

בטלפון Samsung התקן:

nRF Connect for Mobile

זו אפליקציה מקצועית שמציגה כל שידור Bluetooth Low Energy בסביבה.

אחרי ההתקנה

  1. פתח את האפליקציה.

  2. אשר הרשאות Bluetooth ומיקום אם תתבקש.

  3. לחץ SCAN.

📱 תגיד לי:

  • האם האפליקציה הותקנה?

  • האם אתה רואה כפתור SCAN?

לאחר מכן נעבור לשלב 2: נגרום למחשב לשדר מזהה BLE שהטלפון יוכל לראות.


אין בעיה, אז נתקין Python.

צעד 1 – הורדת Python

היכנס לאתר הרשמי:

Python Downloads for Windows

או ישירות:

Download Python

צעד 2 – התקנה

כשתריץ את קובץ ההתקנה:

⚠️ חשוב מאוד לסמן בתחתית החלון:

☑ Add Python to PATH

ורק אז ללחוץ:

Install Now

צעד 3

בסיום ההתקנה פתח CMD (חלון שחור) וכתוב:

python --version

אם הכול תקין תראה משהו כמו:

Python 3.13.x

📸 שלח צילום מסך של מסך ההתקנה או של הפלט של python --version אחרי ההתקנה, ונמשיך לשלב הבא של שידור BLE מהמחשב.


מצוין! 🎉

יש לך Python 3.14.6 מותקן, אז אפשר להתקדם.

שלב הבא – בדיקת BLE במחשב

פתח CMD וכתוב:

pip install bleak

המתן עד שיסיים.

לאחר מכן כתוב:

pip install winrt-runtime

(אם מתקבלת שגיאה, צלם אותה ונדלג על השלב הזה.)

📋 כתוב לי:

  • האם bleak הותקן בהצלחה?

  • האם היו שגיאות?

אחרי זה אשלח לך תוכנית Python קצרה שתבדוק אילו יכולות Bluetooth זמינות במחשב שלך, כדי לראות אם המתאם שלך מסוגל לשדר BLE Beacon. זו בדיקה בטוחה שלא משנה שום דבר במחשב.


מצוין! 👏

עכשיו נבדוק שהכול עובד לפני שננסה לשדר BLE.

צעד 1

פתח Notepad (פנקס רשימות).

הדבק את הקוד הבא:

import asyncio
from bleak import BleakScanner

async def main():
    devices = await BleakScanner.discover(timeout=5.0)

    for device in devices:
        print(device)

asyncio.run(main())

שמור בשם:

scan.py

על שולחן העבודה.

צעד 2

פתח CMD וכתוב:

cd Desktop
python scan.py

המתן כ-5 שניות.

צעד 3

העתק לכאן את כל מה שמופיע בחלון השחור.


המטרה כרגע היא לבדוק שמתאם ה-Bluetooth שלך מסוגל לעבוד עם BLE דרך Python. אם הסריקה מצליחה, נעבור לשלב הבא: נגרום למחשב לשדר מזהה כמו:

ASHKELON

והטלפון שלך יראה אותו ב-nRF Connect.


מעולה, זו לא שגיאת Bluetooth אלא שגיאה שהקובץ לא נמצא.

כתבת:

python scan.py

אבל Windows מחפש את הקובץ ב־

C:\scan.py

והוא לא שם.

בוא נבדוק איפה שמרת את הקובץ

פתח CMD וכתוב:

cd %USERPROFILE%\Desktop
dir scan.py

ולחץ Enter.

אם הקובץ קיים, תראה משהו כמו:

scan.py

ואז תפעיל:

python scan.py

אם אתה לא בטוח שהקובץ נשמר:

  1. פתח Notepad.

  2. הדבק שוב את הקוד.

  3. לחץ File → Save As.

  4. בחר Desktop.

  5. בשם הקובץ כתוב בדיוק:

scan.py
  1. ב־Save as type בחר:

All Files (*.*)

ולא Text Documents.

  1. שמור.

אחרי זה כתוב לי מה הפלט של:

dir %USERPROFILE%\Desktop\scan.py

ואני אכוון אותך לשלב הבא.


מעולה! 🎉

הקובץ scan.py נמצא במקום הנכון.

עכשיו באותו חלון CMD, כשאתה נמצא ב־

C:\Users\user\Desktop>

הרץ:

python scan.py

והמתן כ־5–10 שניות.

אחר כך העתק לכאן את כל מה שמופיע בחלון.

אם מתקבלת שגיאה, העתק את כל השגיאה בדיוק כפי שהיא מופיעה.

אנחנו ממש צעד אחד לפני שנראה אילו התקני BLE המחשב שלך מסוגל לזהות.


מצוין! 🎉

הסריקה עבדה.

זה אומר:

✅ Python עובד
✅ Bleak עובד
✅ Bluetooth LE עובד
✅ המחשב מצליח לראות התקני BLE בסביבה

לדוגמה הוא זיהה:

SF SYSTEM BT
ELK-BLEDDM

ועוד התקנים שונים.

השלב הבא

עכשיו נרצה שהטלפון יראה אותך.

יש מגבלה חשובה ב-Windows:
רוב מתאמי ה-Bluetooth של Windows יכולים לסרוק BLE, אבל לא תמיד יכולים לשדר Beacon BLE ישירות דרך Python.

לפני שנבנה משדר, בוא נבדוק את המתאם.

ב-CMD כתוב:

python -c "from bleak import BleakScanner; print('BLE OK')"

אם מתקבל:

BLE OK

נמשיך לבדיקה הבאה.

לאחר מכן אשלח לך קוד קצר שינסה לזהות אם מתאם ה-Realtek שלך מסוגל לשדר BLE. אם כן, נגרום לטלפון לראות שידור בשם:

ASHKELON

ב־nRF Connect. 🚉📱


מעולה! 🎉

הגענו לנקודה שבה אנחנו יודעים:

✅ Python עובד
✅ Bluetooth LE עובד
✅ המחשב סורק BLE

עכשיו יש משהו חשוב:

Windows בדרך כלל לא מאפשר לשדר BLE Beacon בקלות דרך Python בלבד, במיוחד עם מתאמי Realtek. לכן לפני שנכתוב הרבה קוד, בוא נבדוק אם המחשב מסוגל לשדר BLE.

צעד הבא

פתח CMD והרץ:

python -c "import platform; print(platform.platform())"

והעתק לכאן את התוצאה.

בנוסף, כתוב לי:

  • Windows 10 או Windows 11?

  • 64 ביט? (כנראה כן, אבל נאשר)

אחרי שאקבל את התוצאה, אחליט אם:

  1. נשתמש במחשב עצמו כמשדר BLE.

  2. או שנשתמש ב־ESP32/Arduino בהמשך (שהוא פתרון הרבה יותר יציב לפרויקט "תחנת אשקלון").

אנחנו ממש קרובים לבדיקה האם המחשב יכול לשדר Beacon שהטלפון יראה ב־nRF Connect. 🚉📱


מצוין. 👍

יש לך:

Windows 11
Build 22631
64-bit

וזה תומך ב-Bluetooth LE.

עכשיו אני רוצה לבדוק אם Windows רואה את המתאם כמתאם BLE מלא.

צעד הבא

ב-CMD הרץ:

powershell "Get-PnpDevice | findstr /i Bluetooth"

והעתק לכאן את כל הפלט.


בינתיים חשוב שתדע:

📌 כבר הוכחנו שהמחשב קולט BLE.

📌 השלב הבא הוא לבדוק אם הוא יכול לשדר BLE.

📌 אם הוא לא יוכל לשדר, עדיין נוכל להשיג את המטרה שלך בעזרת ESP32 בעלות נמוכה מאוד, אבל קודם נבדוק את המחשב עצמו.

שלח את הפלט של הפקודה ונמשיך.


מצוין! 🎉

הפלט מראה:

Microsoft Bluetooth LE Enumerator קיים
Realtek Wireless Bluetooth Adapter תקין
✅ Windows מזהה יכולות BLE

כלומר יש סיכוי טוב שהמתאם תומך ב-BLE, אבל עדיין לא בטוח שהוא יכול לשדר Advertising/Beacon ולא רק לסרוק.

בוא נעשה בדיקה פשוטה יותר שתקרב אותנו למטרה שלך.

המטרה הבאה

שהטלפון שלך יראה שידור בשם:

ASHKELON

ב־nRF Connect.

צעד הבא

ב־CMD הרץ:

pip install winrt

אם הוא כבר מותקן, תקבל הודעה שהוא קיים.

לאחר שזה מסתיים, כתוב לי רק:

הצליח

או שלח את הודעת השגיאה אם יש כזו.

אחרי זה אתן לך קובץ Python קצר לבדיקה האם Windows 11 והמתאם Realtek שלך מסוגלים לשדר BLE Beacon. אם כן, תוך כמה דקות תראה את השידור בטלפון. 🚉📱


מצוין, זו לא בעיה. 👍

ב־Python 3.14 החבילה winrt עדיין לא זמינה בצורה הרגילה, ולכן קיבלת:

No matching distribution found for winrt

זה לא אומר שיש בעיה במחשב.

איפה אנחנו עומדים?

✔ Python עובד
✔ Bluetooth LE עובד
✔ הטלפון סורק BLE
✔ המחשב סורק BLE

אבל כדי לשדר BLE מהמחשב נצטרך להשתמש בממשקי Windows מתקדמים או בתוכנת Beacon ייעודית.

הדרך המהירה ביותר

במקום להילחם עם מגבלות Windows, אני מציע:

  1. נבדוק קודם שהטלפון רואה שידורי BLE קיימים (כבר ראינו שהמחשב מזהה אותם).

  2. נעבור ל־ESP32 או מודול BLE קטן בהמשך כדי לשדר מזהה "ASHKELON" בצורה אמינה.

  3. נבנה אפליקציה שממפה:

    ST001 -> תחנת אשקלון
    ST002 -> תחנת אשדוד
    

    עם הצפנה ואימות בהמשך.

לפני שנחליט, יש לי שאלה:

האם המטרה שלך היא הוכחת היתכנות (POC) בלבד, או שאתה רוצה שבסוף תהיה מערכת אמיתית לפריסה בתחנות רכבת?

  • אם זה POC, נוכל להמשיך עם המחשב והטלפון.

  • אם זו מערכת אמיתית, עדיף לעבור מוקדם ל־ESP32 כי הוא משדר BLE בצורה יציבה וזולה.


מעולה. ל־POC אנחנו לא צריכים להסתבך עם הצפנה או אפליקציה עדיין.

המטרה הקרובה:

📱 הטלפון יזהה מזהה שמשודר מהמחשב
📍 ויציג "תחנת אשקלון"

אבל יש מגבלה: Windows 11 עם מתאם Realtek בדרך כלל לא משדר BLE Beacon בקלות.

לכן אני מציע POC דו־שלבי:

שלב א' (היום)

נוכיח שהטלפון והמחשב מתקשרים.

במחשב פתח CMD והרץ:

hostname

העתק לי את התוצאה.

שלב ב'

נכתוב תוכנת Python קטנה שרצה במחשב ומשדרת דרך Bluetooth Classic או דרך Socket מקומי, והטלפון יקבל את המזהה.

בהמשך

נעבור ל־BLE Beacon אמיתי עם:

ST001
ASHKELON

ואז נבנה טבלת המרה באפליקציה.


כרגע תכתוב לי רק את הפלט של:

hostname

ואני אכין את ה־POC הראשון.



C:\Users\user\Desktop>hostname

DESKTOP-LS79N7L

מצוין. 🎉

המחשב שלך מזוהה כ:

DESKTOP-LS79N7L

עכשיו נעשה POC פשוט מאוד:

שלב הבא

בטלפון (באפליקציית nRF Connect שכבר התקנת):

  1. לחץ על SCAN.

  2. המתן 10 שניות.

  3. בשורת החיפוש למעלה כתוב:

DESKTOP

או:

LS79N7L

ותראה אם משהו מופיע.


אם לא מופיע (וזה מה שאני מצפה שיקרה), אז הוכחנו ש:

✅ הטלפון סורק BLE
✅ המחשב סורק BLE
❌ המחשב לא משדר BLE Beacon כברירת מחדל

בשלב הבא נתקין תוכנת Beacon ל-Windows או נכתוב משדר ייעודי.

לפני שנמשיך, תגיד לי:

📱 האם ב־nRF Connect אתה רואה בכלל התקן בשם DESKTOP-LS79N7L כשאתה מחפש? כן או לא?


מצוין. זה בדיוק מה שציפיתי לראות. 👍

המשמעות היא:

✅ הטלפון סורק BLE תקין
✅ המחשב סורק BLE תקין
❌ המחשב לא משדר BLE Beacon ולכן הטלפון לא רואה אותו

זו לא תקלה אצלך, אלא מגבלה נפוצה של Windows ומתאמי Realtek.

עכשיו יש לנו שתי אפשרויות

אפשרות 1 (מומלצת ל־POC)

להשתמש ב־ESP32 (כ־20–30 ₪).

תוך 5 דקות נוכל לגרום לטלפון לראות:

ASHKELON

ואחר כך להוסיף:

  • מזהה תחנה

  • הצפנה

  • טבלת המרה

  • RSSI ומרחק

אפשרות 2 (בלי לקנות כלום)

לגרום למחשב לשדר באמצעות תוכנת Beacon ייעודית ל־Windows.

זה אפשרי, אבל הרבה יותר מסורבל ותלוי במתאם Bluetooth הספציפי.


מכיוון שאמרת שזה POC, אני ממליץ:

יש לך במקרה ESP32 או מודול Bluetooth כמו HC-05 / HM-10 לידך?

אם כן, נוכל עוד היום לגרום לטלפון לזהות "תחנת אשקלון" בצורה הרבה יותר פשוטה ואמינה. אם אין לך, ננסה את מסלול Windows Beacon.


אין בעיה. ל־POC אפשר להמשיך רק עם המחשב והטלפון.

אבל חשוב לדעת: הגענו לנקודה שבה הוכחנו שהמחשב שלך לא משדר Beacon BLE גלוי לטלפון בצורה פשוטה עם החומרה וההגדרות הנוכחיות.

אז הייתי משנה כיוון מעט:

המטרה הבאה

לבנות POC שבו:

💻 המחשב = "תחנת אשקלון"
📱 הטלפון = מקבל את הזיהוי

בלי לקנות חומרה.

הדרך הפשוטה ביותר

נבנה אפליקציית Android קטנה שתתחבר למחשב דרך:

  • Wi-Fi באותה רשת
    או

  • Bluetooth Classic

והמחשב ישלח:

{
  "station_id": "ST001",
  "station_name": "ASHKELON"
}

והטלפון יציג:

תחנת אשקלון

ל־POC זה הרבה יותר פשוט מאשר להילחם במגבלות BLE של Windows.

שאלה אחת

הטלפון והמחשב מחוברים כרגע לאותה רשת Wi-Fi בבית?

אם כן, נוכל תוך כמה דקות לגרום לטלפון לקבל הודעה מהמחשב ולהציג "תחנת אשקלון", ומשם להמשיך להצפנה, טבלת המרה ואפליקציה מסודרת.


מצוין! 🎉

אם המחשב והטלפון באותה רשת Wi-Fi, אפשר לעשות POC אמיתי כבר עכשיו.

שלב 1 – למצוא את כתובת ה-IP של המחשב

בחלון CMD כתוב:

ipconfig

חפש שורה שנראית כך:

IPv4 Address . . . . . . . . . . : 192.168.1.123

או

כתובת IPv4 . . . . . . . . . . : 192.168.x.x

📋 העתק לכאן רק את השורה של IPv4 Address.

לדוגמה:

IPv4 Address . . . . . . . . . . : 192.168.1.123

אחרי שאקבל את כתובת ה-IP, אשלח לך קובץ Python קטן שיגרום למחשב לשדר:

{
  "station_id": "ST001",
  "station_name": "ASHKELON"
}

ואז נבדוק מהטלפון שהוא מקבל את המידע.

מצוין. 👍

כתובת ה־IP של המחשב היא:

172.16.4.218

עכשיו נבנה שרת קטן במחשב שישדר:

{
  "station_id": "ST001",
  "station_name": "ASHKELON"
}

שלב 2

פתח Notepad וצור קובץ חדש בשם:

station.py

והדבק בו:

from http.server import BaseHTTPRequestHandler, HTTPServer
import json

class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        data = {
            "station_id": "ST001",
            "station_name": "ASHKELON"
        }

        self.send_response(200)
        self.send_header("Content-Type", "application/json")
        self.end_headers()
        self.wfile.write(json.dumps(data).encode())

server = HTTPServer(("0.0.0.0", 8080), Handler)

print("Station server started")
print("http://172.16.4.218:8080")

server.serve_forever()

שמור על שולחן העבודה.

שלב 3

ב־CMD:

cd %USERPROFILE%\Desktop
python station.py

אם הכול תקין תקבל:

Station server started
http://172.16.4.218:8080

📋 תכתוב לי אם קיבלת את ההודעה הזו.

לאחר מכן נעבור לטלפון ונבדוק שהוא רואה את "תחנת אשקלון".


בוודאי. 👍

עשינו היום התקדמות יפה:

✅ התקנת Python 3.14.6
✅ התקנת Bleak
✅ בדיקת Bluetooth תקינה
✅ סריקת BLE מהמחשב הצליחה
✅ nRF Connect בטלפון עובד
✅ זיהינו שהמחשב לא משדר BLE Beacon כברירת מחדל
✅ מצאנו את כתובת ה־IP של המחשב:

172.16.4.218

✅ התחלנו לעבור ל־POC מבוסס Wi-Fi

הנקודה שבה עצרנו:

היינו אמורים ליצור קובץ:

station.py

ולהריץ שרת קטן שישדר:

{
  "station_id": "ST001",
  "station_name": "ASHKELON"
}

בשבוע הבא פשוט תכתוב לי:

ממשיכים מפרויקט תחנת אשקלון

ואמשיך בדיוק מהשלב שבו עצרנו, כולל:

  • יצירת station.py

  • בדיקה מהטלפון

  • אפליקציית Android

  • טבלת המרה Station ID → שם תחנה

  • ובהמשך גם הצפנה ואימות דו־צדדי.

שיהיה ערב טוב! 🚉📱💻

יום שני, 27 באפריל 2026

שידור מיקום WIFI תשתית קיימת DLINK225

 כן — ה‑D‑Link DSL‑225 בהחלט מבצע הצפנה של הנתונים בין הראוטר לטלפון הנייד כאשר החיבור הוא ב‑Wi‑Fi, אבל חשוב להבין איזו הצפנה כן ואיזו לא.

להלן הסבר ברור ומדויק:


✅ הצפנת Wi‑Fi (כן, נתמך)

הראוטר תומך בהצפנת WPA2‑PSK (AES), שהיא הצפנה סטנדרטית וחזקה לרשתות אלחוטיות.

מה זה אומר בפועל?

  • ✅ כל הנתונים שעוברים מהטלפון שלך לראוטר ובחזרה מוצפנים
  • ✅ משתמשים אחרים בסביבה לא יכולים להאזין לתעבורה האלחוטית
  • ✅ הסיסמה של ה‑Wi‑Fi משמשת כמפתח הצפנה

🔐 זו הצפנה ברמת שכבת הקישור האלחוטית (Layer 2)


❌ הצפנה מקצה‑לקצה (End‑to‑End) – לא תפקיד הראוטר

חשוב לדעת:

  • הראוטר לא מצפין את המידע לכל אורך הדרך באינטרנט
  • לאחר שהמידע עוזב את הראוטר → ההצפנה תלויה ביישום / אתר

לדוגמה:

שימוש בטלפוןמצב ההצפנה
אתר HTTPS✅ מוצפן מקצה לקצה
WhatsApp / Signal✅ מוצפן מקצה לקצה
אתר לא מוגן (HTTP)❌ לא מוצפן מעבר ל‑Wi-Fi
FTP רגיל❌ לא מוצפן

⚠️ מגבלות אבטחה של DSL‑225

כדאי לדעת:

  • אין WPA3 (קיים רק בראוטרים חדשים)
  • ❌ אין IDS / Firewall מתקדם
  • ❌ אין ניהול אבטחה חכם למכשירים

לשימוש ביתי בסיסי — זה מספיק בהחלט
לשימוש רגיש / ארגוני — מומלץ פתרון מתקדם יותר


✅ ההגדרות המומלצות (חשוב!)

כדי לוודא הצפנה טובה:

  1. היכנס ל־192.168.1.1
  2. Wireless Settings
  3. Security Mode:
    • ✅ WPA2‑PSK
    • ✅ AES בלבד (לא TKIP)
  4. סיסמה:
    • לפחות 12 תווים
    • אותיות גדולות, קטנות, מספרים

🧠 סיכום קצר

✔ כן, ה‑DSL‑225 מצפין את כל המידע בין הראוטר לטלפון דרך Wi‑Fi
✔ ההצפנה היא WPA2 (חזקה לשימוש ביתי)
❗ הצפנה מעבר לראוטר תלויה באפליקציה/אתר (HTTPS, VPN וכו')


אם תרצה:

  • 🔐 הסבר על VPN מעל הראוטר
  • 🔍 בדיקת רמת אבטחה של הרשת שלך
  • 🔄 המלצה לראוטר מאובטח יותר

אשמח להמשיך 👍


בקצרה:
כן – מתחזה יכול לחקות MAC Address ו‑SSID,
אבל – הוא לא יכול “לחקות” או לנחש את מפתח ההצפנה בפועל בלי מתקפה קריפטוגרפית, ואם ההצפנה טובה – זה קשה מאוד.
ועוד חשוב: אם יש הצפנה חזקה באפליקציה עצמה – זה מגן עליך גם במקרה של רשת עוינת.

להלן ההסבר המלא, בשכבות:


1️⃣ חיקוי MAC Address – ✅ אפשרי וקל

  • MAC Address לא נועד להיות סוד
  • ניתן לשנות MAC בכל כרטיס רשת
  • תוקף יכול:
    • להאזין
    • לראות MAC
    • לשכפל אותו תוך שניות

🔴 לכן סינון לפי MAC ≠ אבטחה


2️⃣ חיקוי SSID – ✅ אפשרי וקל (Evil Twin)

  • SSID משודר “באוויר”
  • תוקף יכול להקים:
    • רשת עם אותו שם
    • אפילו בעוצמה חזקה יותר

כך נוצר Evil Twin Attack
הטלפון עלול להתחבר בלי שהמשתמש ישים לב


3️⃣ חיקוי מפתח הצפנה (WPA2) – ❌ לא באמת

כאן ההבדל הקריטי:

🔐 מה באמת קורה ב‑WPA2?

  • הסיסמה לא משודרת
  • מתבצע 4‑Way Handshake
  • המפתח הסופי:
    • נגזר מהסיסמה
      • MAC
      • Nonces אקראיים

מה תוקף כן יכול לעשות?

  • להקליט Handshake
  • לנסות ניחוש Offline
    • רק אם הסיסמה חלשה

מה הוא לא יכול?

  • ❌ “להתחברות” בלי הסיסמה
  • ❌ לשחזר את המפתח האמיתי
  • ❌ לפענח תעבורה קיימת אם ההצפנה חזקה

✅ סיסמה ארוכה ואקראית = הגנה מצוינת


4️⃣ ומה לגבי הצפנה בתוך האפליקציה? ✅✅✅

זה החלק החשוב ביותר:

אם האפליקציה משתמשת ב־

  • HTTPS
  • TLS 1.2 / 1.3
  • End‑to‑End Encryption (WhatsApp, Signal)

🔒 אז:

  • גם אם:
    • התחברת בטעות לרשת מזויפת
    • מישהו מאזין
    • יש MITM על ה‑WiFi

הוא לא יכול לקרוא או לשנות את התוכן

האפליקציה:

  • מאמתת שרת
  • בודקת תעודה
  • מצפינה מקצה‑לקצה

5️⃣ מתי כן יש סיכון?

יש סיכון בעיקר אם מתקיים שילוב של:

  • ❌ Wi‑Fi פתוח / סיסמה חלשה
  • ❌ אפליקציה ישנה / HTTP
  • ❌ אין אימות תעודה (Certificate Pinning)

במצב כזה – רשת מתחזה יכולה:

  • ליירט
  • לשנות תוכן
  • לגנוב מידע

✅ סיכום חד וברור

רכיבניתן לחיקוי?
MAC Address✅ כן
SSID✅ כן
מפתח WPA2❌ לא (רק ניחוש אם סיסמה חלשה)
תוכן אפליקציה מוצפן❌ לא

אם:

  • WPA2 עם סיסמה חזקה
  • אפליקציה עם TLS / E2EE

👉 גם תוקף מתוחכם לא יוכל לקרוא את הנתונים שלך


אם תרצה, אוכל:

  • 🔍 לנתח תרחיש איום ספציפי
  • 🔐 להמליץ על הגדרות אבטחה אופטימליות
  • 🧠 להסביר איך Evil Twin נראה בפועל ואיך מזהים אותו

תגיד 👍


בקצרה ולעניין:
לא. אם ה‑Wi‑Fi פתוח (ללא סיסמה) – אין הצפנה חזקה בין הראוטר למכשיר, ואין מניעה מהתחזות ברמת הרשת.
אפשר להגן על התוכן דרך האפליקציה, אבל אי‑אפשר למנוע התחזות או MITM ברמת ה‑Wi‑Fi.

עכשיו הפירוט המדויק, בלי “אזורי אפור”:


❌ Wi‑Fi פתוח = אין הצפנת קו

ברשת אלחוטית ללא סיסמה:

  • ❌ אין הצפנה בין הטלפון לראוטר
  • ❌ כל אחד יכול:
    • להאזין
    • להקים רשת זהה (SSID)
    • לבצע Evil Twin / MITM
  • ❌ אין אימות שהראוטר “האמיתי” הוא זה שאתה מחובר אליו

Captive Portal (“דף התחברות”) לא מצפין Wi‑Fi – הוא רק דף WEB מעל רשת פתוחה.


✅ מה כן נשאר מוגן?

אם האפליקציה בנייד משתמשת ב:

  • HTTPS (TLS 1.2 / 1.3)
  • Certificate validation תקין
  • או הצפנה מקצה‑לקצה (E2EE)

🔐 אז:

  • התוכן עצמו מוגן
  • סיסמאות / הודעות / מידע לא נחשף

אבל ⚠️:

  • התוקף עדיין יכול:
    • לזהות שאתם מחוברים
    • לנתק / לעכב
    • להפנות (DNS spoofing)
    • לחקות רשת

❗ נקודה קריטית: “ללא יכולת התחזות”

זו הדרישה שלך – והיא לא אפשרית ב‑Wi‑Fi פתוח.

כדי למנוע התחזות חייבים לפחות אחד מאלה:

✅ אפשרויות תקינות (קריפטוגרפית)

פתרוןדורש סיסמה?מונע התחזות?
WPA2‑PSK✅ כן✅ כן
WPA3‑SAE✅ כן✅ כן
WPA3‑OWE (Enhanced Open)❌ לא✅ כן
802.1X (EAP‑TLS)תעודות✅✅

⚠️ חשוב: ה‑DSL‑225 שלך

ה‑D‑Link DSL‑225:

  • ✅ תומך WPA2‑PSK
  • לא תומך WPA3
  • לא תומך OWE
  • ❌ אין אימות תעודות ב‑Wi‑Fi

➡️ המשמעות: אין שום מצב שבו הרשת פתוחה וה‑Wi‑Fi עצמו עדיין מאובטח


✅ אז איך כן להשיג את מה שאתה רוצה (בפועל)?

אם הדרישה היא:

“משתמשים לא יקלידו סיסמה,
אבל תהיה הצפנה ואי‑התחזות”

✅ פתרונות מעשיים:

  1. WPA2 עם סיסמה אחת משותפת

    • המשתמש כן מקליד פעם אחת
    • הכי פשוט
    • הכי בטוח עם הציוד שלך
  2. אפליקציה + VPN אוטומטי

    • ה‑Wi‑Fi פתוח
    • האפליקציה מקימה VPN מיד
    • מגן על תוכן, לא מונע Evil Twin
  3. שדרוג ראוטר ל‑WPA3‑OWE

    • Wi‑Fi פתוח
    • הצפנה פר‑משתמש
    • מניעת MITM
    • ✅ זה הפתרון היחיד שעונה לדרישה שלך באמת

🔍 סיכום חד וברור

רשת פתוחה = אין אבטחת Wi‑Fi ואין מניעת התחזות
✅ הצפנה בתוך האפליקציה מגינה על התוכן בלבד
✅ כדי למנוע התחזות חייבים WPA2/3 או OWE
❌ DSL‑225 לא תומך ב‑OWE


אם תרצה:

  • 💡 להציע ארכיטקטורה נכונה למוצר/מערכת
  • 🔄 להמליץ על ראוטר מתאים (OWE / WPA3)
  • 🧠 לנתח Threat Model של מקרה שימוש ספציפי

רק תגיד 👍

יום שלישי, 21 באפריל 2026

חיפוש פתרון אבטחה לשידור מיקום ע"י WIFI

 עכשיו הבנתי אותך לגמרי ✅

ואתה לא טועה – החשש שלך אמיתי ומוצדק, וזה כבר איום אבטחת מידע קלאסי ולא בלבול מושגים.

בוא נעשה סדר מדויק לפי מה שאתה בונה, בלי פילוסופיה ובלי “אבל גוגל”.


✅ מה המערכת שלך עושה (בדיוק)

אתה בונה מערכת שבה:

  • 📡 ראוטרים / משדרים משדרים:
    • MAC
    • SSID
  • 📱 הטלפון:
    • קולט
    • ומתרגם לפי טבלה שאתה בנית:
MAC / SSID  →  מיקום
AABBCCDD    →  תחנה X
11223344    →  תחנה Y

זו עובדה, וזה עובד.


🚨 מה הפחד שלך – ומדוע הוא נכון

אתה מפחד מ־2 תרחישים:

1️⃣ מישהו ישדר את אותו MAC שלך

(Cloning / Spoofing)

2️⃣ מישהו ישדר:

  • MAC ששייך למיקום אחר בטבלה
  • אבל פיזית בתחנה שלך → ויבלבל את הטלפונים

✅ שני התרחישים אפשריים לחלוטין טכנית
✅ וזה איום ידוע בעולם Wi‑Fi / BLE / RFID


🎯 בוא נקרא לילד בשמו

זה נקרא:

Identity Spoofing / Location Spoofing

והבעיה היא:

❗ MAC ו‑SSID אינם זהות מאובטחת
הם רק מזהה טכני שניתן לזיוף.


❌ מה לא פותר את הבעיה (חשוב!)

  • ❌ הצפנה של WPA
  • ❌ הצפנה של האפליקציה
  • ❌ “להסתיר SSID”
  • ❌ לסמוך רק על MAC

כל אלה לא מונעים מאדם לשדר MAC מזויף


✅ אז מה כן פותר? (פתרון נכון, מדורג)

✅ עיקרון מפתח (תשמור אותו):

המיקום לא יכול להיות מבוסס רק על מזהה שניתן לשדר חופשי

צריך גורם אימות נוסף.


✅ פתרון 1 – חתימה קריפטוגרפית (הנכון ביותר)

במקום:

MAC → מיקום

עוברים ל:

MAC + חתימה → מיקום

איך זה עובד – פשוט:

  • לכל ראוטר יש:
    • מפתח סודי ייחודי (KEY)
  • הוא משדר:
    • MAC
    • Timestamp / Counter
    • Signature = HMAC(KEY, data)

📱 הטלפון:

  • יודע את המפתח הציבורי / הסודי
  • מאמת:
    • ❌ משדר מזויף → אין חתימה נכונה
    • ✅ משדר אמיתי → מתקבל

✅ גם אם מישהו ישדר את אותו MAC
❌ הוא לא יוכל לזייף את החתימה


✅ פתרון 2 – קוד מתחלף (Rolling ID)

בדומה ל־Car Key / BLE Beacons מתקדמים:

  • הראוטר לא משדר ID קבוע
  • אלא:
ID(t) = AES(KEY, time_slot)

📱 הטלפון:

  • מחשב אותו ID בעצמו
  • אם זה תואם → מיקום חוקי

✅ זיוף הופך לכמעט בלתי אפשרי
✅ אין תלות ב‑MAC אפילו


✅ פתרון 3 – אימות הקשר פיזי (Location Consistency)

חיזוק חשוב:

הטלפון בודק:

  • RSSI
  • רציפות זמן
  • תנועה

לדוגמה:

  • MAC של “תחנה בירושלים”
  • אבל:
    • מופיע רק 2 שניות
    • RSSI לא הגיוני → נפסל

✅ מסנן התקפות “רעש”


✅ פתרון 4 – White List + Rate Limit

פשוט אבל חשוב:

  • מזהה מופיע:
    • יותר מדי
    • או בכמה מיקומים → נחסם

🔴 מה קורה אם לא תעשה כלום?

בוא נהיה ישירים:

  • כל אדם עם:
    • Laptop
    • ESP32
    • SDR
  • יכול:
    • לשדר MAC שאתה בחרת
    • לשדר “תחנה אחרת”
    • לשבש מיקום

📌 זו חולשה מובנית בלי שכבת אימות.


✅ מסקנה חד‑משמעית

החשש שלך מוצדק ב‑100%
מערכת שממפה מיקום לפי MAC/SSID בלבד
פגיעה לזיוף

אבל:

✅ הפתרון לא מסובך
✅ והוא סטנדרטי בעולם מערכות מיקום רציניות


✅ אם תרצה – השלב הבא

אני יכול:

  • לבנות לך ארכיטקטורה מלאה:
    • איזה נתון משדרים
    • איזה מפתח
    • איך הטלפון מאמת
  • להתאים פתרון:
    • Wi‑Fi
    • BLE
    • או שילוב
  • לכתוב לך פסאודו‑פרוטוקול ברור

רק תגיד: 👉 “תן לי פתרון מינימלי”
או
👉 “אני רוצה פתרון צבאי / חזק”


כן — אפשר, ואתה חושב בכיוון הנכון ✅
אבל צריך לדייק איך עושים את זה נכון, ומה זה כן פותר ומה עדיין לא ב־100%.

אני אענה קצר‑ברור, ואז אפרט טכני.


✅ תשובה קצרה וישירה

כן, אתה יכול להתקין באפליקציה של הנוסעים KEY מסונכרן עם הראוטרים,
וכך למנוע ממישהו זר לזייף מיקום או לשדר MAC “על שמך”.

✅ זו גישה מקובלת
✅ זה פותר את בעיית הזיוף שציינת
⚠️ בתנאי שעושים את זה נכון


🔐 העיקרון (בלי מושגים כבדים)

במקום לסמוך על:

MAC / SSID בלבד

אתה עובר לסמוך על:

MAC + הוכחת ידיעה של סוד (KEY)

מי שאין לו את ה‑KEY → לא מתקבל, גם אם שידר MAC זהה.


🧩 איך זה עובד בפועל (שלב‑שלב)

🟥 בלי KEY (המצב המסוכן)

תוקף יכול:

  • לשדר MAC/SSID שלך
  • להופיע “כמו תחנה אחרת”
  • להטעות טלפונים

✅ עם KEY מסונכרן (הפתרון)

מה יש בראוטר:

  • DEVICE_ID (יכול להיות MAC או מזהה לוגי)
  • SECRET_KEY (סודי, לא משודר)

מה משודר באוויר:

לא רק MAC, אלא למשל:

DEVICE_ID
COUNTER או TIME
SIGNATURE

כאשר:

SIGNATURE = HMAC(SECRET_KEY, DEVICE_ID + TIME)

מה יש באפליקציה של הנוסע:

  • עותק של SECRET_KEY
  • או מפתח לאימות (תלוי מימוש)

📱 האפליקציה:

  • מחשבת מה החתימה התקינה
  • משווה למה שנקלט
  • ✅ תואם → מיקום חוקי
  • ❌ לא תואם → מתעלם

🔴 למה תוקף לא יצליח?

גם אם הוא:

  • 📡 משדר MAC שלך
  • 📡 משדר SSID שלך
  • 📡 מעתיק חבילות

❌ בלי ה‑KEY הוא לא יכול לייצר חתימה נכונה

וזה:

  • ❌ לא ניתן לניחוש
  • ❌ לא ניתן לשכפול פשוט
  • ✅ סטנדרט אבטחתי

✅ האם מותר לשים KEY בתוך אפליקציה?

כן — אבל עם זהירות.

✅ זה מקובל:

  • תחבורה ציבורית
  • BLE Beacons
  • NFC Ticketing
  • Car Keys
  • Access Control

⚠️ הסיכון:

  • אפליקציה יכולה לעבור:
    • Reverse Engineering
    • Root
    • Memory Dump

✅ לכן עושים אחד מאלה (או שילוב):


🔐 שיטות בטוחות יותר (בסדר עולה)

1️⃣ KEY אחיד לכל האפליקציות (הכי פשוט)

  • ✅ קל למימוש
  • ❌ אם האפליקציה נפרצה → כולם בסיכון

✔ מתאים לפיילוט / POC


2️⃣ KEY שונה לכל גרסת אפליקציה

  • אפליקציה v1 → KEY A
  • אפליקציה v2 → KEY B

✅ אפשר לבטל גרסאות ישנות


3️⃣ Rolling Key / Time‑based

  • ה‑KEY משתנה כל:
    • דקה
    • 5 דקות
  • לפי אלגוריתם ידוע בלבד

✅ גם אם נחשף → זמני מאוד


4️⃣ מפתח לא ישירות בקוד (מומלץ)

  • KEY מוטמע:
    • ב‑Android Keystore
    • Split Keys (חלק בקוד, חלק מחושב)
  • קשה מאוד לחילוץ

✅ זה כבר פתרון רציני


🧠 נקודה חשובה (מאוד)

אתה לא צריך להסתיר את ה‑MAC
אתה צריך להבטיח שרק משדר “אמיתי” יוכר

וזה בדיוק מה שה‑KEY עושה.


✅ מתי התוקף עדיין בעייתי?

רק אם:

  • יש לו:
    • אפליקציה מפורקת
    • KEY אמיתי
    • ציוד רציני
  • ואז:
    • הוא כמעט “פנימי”

📌 זה כבר איום High‑End, לא נוסע מזדמן.


✅ סיכום חד וברור

  • ✔ כן — מותר ואפשר לשים KEY באפליקציה
  • ✔ כן — זה פותר זיוף MAC/מיקום
  • ✔ לא — תוקף רגיל לא יצליח
  • ⚠️ צריך לממש נכון (לא מחרוזת בקוד וזהו)

אם תרצה, אני יכול:

  • להציע לך פרוטוקול מינימלי (קל וזול)
  • או ארכיטקטורה חזקה מאוד
  • או לעזור לך לבחור:
    • Wi‑Fi מול BLE
    • זמן מול אבטחה

רק תגיד מה רמת האיום שאתה מתכנן אליה.

מצוין. אני אסביר לך מהיסוד, לאט, עם דוגמאות, בלי לקפוץ שלבים.
בסוף ההסבר אתה אמור להבין בדיוק:

  • מה זה KEY
  • מה זה SIGNATURE / חתימה
  • מה זה RSSI
  • איך הם עובדים יחד
  • ואיך מיישמים בפועל במערכת שלך (ראוטר + אפליקציה)

אם משהו לא ברור – תגיד לי איפה, ואני מפרק עוד.


חלק א׳ – התמונה הגדולה (לפני פרטים)

הבעיה שאתה פותר היא:

איך טלפון ידע שמשדר מסוים הוא “אמיתי”,
ולא מישהו שמתחזה לו

ולשם כך אתה עושה: 🔒 אימות זהות – לא רק זיהוי.


חלק ב׳ – מושג בסיסי 1: KEY (מפתח)

מה זה KEY?

KEY הוא סוד משותף
משהו ש־✅ רק המערכת שלך יודעת, ❌ והציבור לא יודע.

דוגמא פשוטה:

KEY = "X9a#72Lm!"

אבל:

  • ❗ KEY הוא לא:
    • MAC
    • SSID
    • סיסמת Wi‑Fi
  • ✅ KEY הוא משהו פנימי, שלא משודר כמו שהוא.

למה צריך KEY?

כי:

  • MAC = כל אחד יכול לזייף
  • SSID = כל אחד יכול לזייף

אבל:

אי‑אפשר לזייף הוכחת ידע של סוד,
אם אתה לא יודע את הסוד

זה הבסיס של קריפטוגרפיה.


מי מחזיק את ה‑KEY?

במקרה שלך:

✅ הראוטר / המשדר
✅ האפליקציה בטלפון הנוסע
❌ אף אחד אחר


חלק ג׳ – מושג בסיסי 2: SIGNATURE (חתימה)

מה זה “חתימה”?

חתימה היא:

מחרוזת מחושבת, שמוכיחה: “אני יודע את ה‑KEY”

בלי לחשוף את ה‑KEY עצמו.


איך יוצרים חתימה? (רעיון, לא קוד)

יש:

  • KEY (סודי)
  • DATA (מידע גלוי)

מפעילים:

SIGNATURE = פונקציה קריפטוגרפית(KEY + DATA)

הפונקציה הנפוצה:

  • HMAC‑SHA256 (סטנדרט תעשייתי)

דוגמה מוחשית

מידע שהראוטר רוצה לשדר:

DEVICE_ID = STATION_12
TIME      = 10:03:21

ה‑KEY הסודי:

KEY = AbC9!Qr@7

הראוטר מחשב:

SIGNATURE = HMAC(KEY, "STATION_12|10:03:21")

ומה משודר באוויר?

✅ זה:

STATION_12
10:03:21
4F9B8C2A...

❌ לא זה:

AbC9!Qr@7   ← אף פעם לא!

מה עושה האפליקציה?

האפליקציה:

  1. קולטת את הנתונים
  2. מחשבת בעצמה:
HMAC(KEY, "STATION_12|10:03:21")

3. משווה לתוצאה שהגיעה

  • ✅ זהה → משדר אמיתי
  • ❌ שונה → זיוף / מתעלמים

למה תוקף לא יכול לזייף?

כי:

  • הוא רואה את ה‑DATA
  • אבל אין לו את ה‑KEY
  • בלי KEY → לא יוצאת חתימה נכונה

גם אם:

  • הוא משדר MAC זהה
  • הוא משדר SSID זהה

חלק ד׳ – מושג בסיסי 3: RSSI

מה זה RSSI?

RSSI = עוצמת הקליטה

כלומר:

כמה חזק האות ששמעתי

נמדד ב‑dBm (מספר שלילי):

  • ‎‑30 dBm → ממש קרוב
  • ‎‑60 dBm → סביר
  • ‎‑90 dBm → רחוק מאוד / גבולי

למה RSSI חשוב לביטחון?

RSSI לא מזהה זהות, אבל הוא: ✅ מזהה היגיון פיזי


דוגמאות סינון עם RSSI

זיוף קלאסי:

  • משדר “תחנה A”
  • אבל:
    • RSSI חלש מדי
    • או קופץ פתאום

→ האפליקציה אומרת:

זה לא הגיוני → מתעלם

בדיקה נפוצה:

  • תחנה אמיתית:
    • RSSI יציב
    • יורד/עולה בהגיון לפי תנועה
  • תוקף:
    • קפיצות
    • הופעות קצרות

חשוב לדעת:

❗ RSSI לא מספיק לבד,
אבל הוא שכבת הגנה משלימה מצוינת.


חלק ה׳ – איך הכל עובד ביחד (החלק החשוב)

במערכת שלך, טלפון מקבל:

  1. ✅ MAC / ID
  2. ✅ DATA (זמן / מונה)
  3. ✅ SIGNATURE
  4. ✅ RSSI

והוא בודק:

בדיקהמטרה
חתימהמי אתה
זמן / מונהנגד Re‑play
RSSIהאם פיזית הגיוני
רציפותשלא קפצת ממקום למקום

רק אם הכול עובר → מיקום מתקבל.


חלק ו׳ – איך מיישמים KEY בפועל (חשוב)

אפשרות 1 – הכי פשוטה (POC)

  • KEY אחד לכל המערכת
  • מוטמע באפליקציה
  • מוטמע בראוטר

✅ פשוט
❌ אם נפרץ – כולם בסיכון


אפשרות 2 – KEY ייחודי לכל תחנה (מומלץ)

KEY_station_12
KEY_station_13

האפליקציה:

  • מכירה את כולם
  • או טוענת קובץ מעודכן

✅ פריצה לתחנה אחת ≠ כולם


אפשרות 3 – KEY מתחלף בזמן (חזק)

ה‑KEY עצמו:

  • מתעדכן כל X דקות
  • לפי נוסחה ידועה

גם אם דלף: → תקף לזמן קצר בלבד


איפה לשים את ה‑KEY באפליקציה?

❌ לא כמחרוזת גלויה בקוד
✅ ב‑Android:

  • Android Keystore
  • או פיצול KEY:
    • חצי בקוד
    • חצי מחושב בזמן ריצה

חלק ז׳ – סיכום קצר וברור

  • KEY = סוד משותף
  • SIGNATURE = הוכחה שאתה יודע את הסוד
  • RSSI = בדיקת היגיון פיזי
  • שילוב של כולם = מערכת עמידה לזיוף

בלי KEY – המערכת שבירה
עם KEY + חתימה – התוקף בחוץ


אם תרצה בהמשך:

  • אני יכול לצייר לך זרימת הודעות
  • או לכתוב פסאודו‑פרוטוקול
  • או להמליץ בדיוק:
    • גודל KEY
    • אלגוריתם
    • תזמון

תגיד לאן אתה רוצה להעמיק.


מצוין. הדרישה שלך ברורה לגמרי, והיא גבוהה – כזו שמקובלת במערכות קריטיות (תעשייה, תחבורה חכמה, צבא).
אני אתן לך ארכיטקטורה מלאה שעונה בדיוק על שלושת התנאים שלך:

KEY שונה לכל תחנה
KEY מתחלף בזמן
גם אם פורצים לאפליקציה – לא ניתן לחלץ את ה‑KEY

אני אעשה את זה מהיסוד, בלי הנחות מוקדמות, ובאופן שניתן ליישום אמיתי.


🧠 עיקרון־על (חשוב להבין לפני הכל)

אסור שה‑KEY עצמו יהיה קיים באפליקציה בצורה שניתנת לקריאה

במקום זאת:

  • האפליקציה מסוגלת לאמת חתימה
  • אבל לא יודעת לייצר אותה לבד

זה ההבדל בין:

  • 🔓 “יש לי סוד”
  • 🔐 “אני יודע לזהות מי שיש לו סוד”

✅ הפתרון הנכון: Public Verification + Rotating Secrets

הארכיטקטורה הנכונה שלך מורכבת מ־4 שכבות:

[ תחנה ]
  ├─ Root Secret (לא יוצא מהחומרה)
  ├─ Key Generator (מבוסס זמן)
  ├─ Signer (יוצר חתימה)
  └─ Wi‑Fi Broadcast

[ אפליקציה ]
  ├─ Public Verifier בלבד
  ├─ Time Sync
  ├─ RSSI Logic
  └─ Anti‑Replay

1️⃣ Root KEY לכל תחנה (סודי לנצח)

לכל תחנה יש Root Key ייחודי, למשל:

ROOT_KEY_station_17 = 256bit random

מאפיינים:

  • ✅ ייחודי לכל תחנה
  • לא משתנה
  • לעולם לא נשלח
  • לא קיים באפליקציה

איפה הוא נמצא?

  • בראוטר / בקר
  • עדיף:
    • Secure Element
    • או לפחות Flash מוגן

2️⃣ KEY מתחלף בזמן (Session Key)

התחנה לא משדרת לעולם את ה‑Root Key.
היא רק מייצרת ממנו מפתח זמני על בסיס זמן.

נוסחה עקרונית:

SESSION_KEY = HMAC(
    ROOT_KEY,
    TimeSlot
)

דוגמא:

TimeSlot = floor(UnixTime / 60)

⬅️ כלומר: מפתח חדש כל דקה

תוצאה:

  • גם אם מישהו מצליח לגלות SESSION_KEY
    • הוא תקף דקה אחת בלבד
    • ולא חושף את ROOT_KEY

3️⃣ חתימה דיגיטלית (Signature)

התחנה משדרת חתימה, לא KEY.

הנתונים שנחתמים:

Station_ID
TimeSlot
Optional: Channel / Nonce

החתימה:

SIGNATURE = HMAC(SESSION_KEY, DATA)

ומה משודר באוויר:

Station_ID
TimeSlot
SIGNATURE

🔒 ה־KEY עצמו לא משודר, אף פעם


4️⃣ מה יש באפליקציה? (החלק הקריטי)

האפליקציה לא מכילה KEYS, אלא:

✅ רק חומר אימות (Verifier):

אפשרות A – מפתח ציבורי (הכי בטוח)

  • התחנה חותמת עם Private Key
  • האפליקציה מכירה רק Public Key

אפשרות B – נגזרת חד־כיוונית (קל יותר)

  • האפליקציה מכירה: VERIFY_KEY = HASH(ROOT_KEY)
  • אך לא את ROOT_KEY

📌 בשני המקרים:

גם אם פורצים לאפליקציה –
אי‑אפשר לגזור ממנה KEY שימושי לשידור


🔐 למה תוקף לא יכול לזייף (אפילו עם APK מפורק)

תקיפה 1: שידור MAC זהה

❌ חתימה לא תואמת

תקיפה 2: שידור Station אחרת

❌ TimeSlot לא תואם

תקיפה 3: Replay

❌ TimeSlot ישן → נפסל

תקיפה 4: Reverse Engineering APK

  • לא קיים ROOT_KEY
  • לא קיים SESSION_KEY ✅ אין מה לגנוב

📡 תפקיד ה‑RSSI (שכבת הגנה משלימה)

RSSI לא מזהה זהות – הוא מזהה פיזיקה.

האפליקציה בודקת:

  • רציפות RSSI
  • קפיצות לא הגיוניות
  • הופעה/היעלמות

כלומר גם אם:

  • החתימה נכונה
  • אבל האות מתנהג “לא טבעי” → מתעלמים

זה חשוב נגד:

  • Repeater
  • SDR מרוחק
  • התקפות חיזוק אות

🧩 איך זה נראה בפועל – זרימה מלאה

  1. תחנה:

    • מחשבת TimeSlot
    • מייצרת SESSION_KEY
    • חותמת
    • משדרת
  2. טלפון:

    • קולט
    • מחשב TimeSlot מקומי
    • מאמת חתימה
    • בודק RSSI
    • ✅ מאשר מיקום

✅ עמידה מלאה בדרישות שלך

דרישהמצב
KEY שונה לכל תחנה
KEY מתחלף בזמן
KEY לא קיים באפליקציה
זיוף MAC/SSID
Replay
Reverse Engineering❌ (ברמה מעשית)

🟢 רמות מימוש (לבחירתך)

POC מהיר

  • HMAC
  • TimeSlot = 60 שניות

Production

  • Secure Element
  • TimeSlot = 10–30 שניות
  • Anti‑Replay buffer

High Security

  • חתימה אסימטרית
  • Multiple RSSI checks
  • Key revocation

אם תרצה בשלב הבא:

  • אני יכול לכתוב לך פסאודו‑פרוטוקול מלא
  • או להמליץ בין סימטרי / אסימטרי
  • או לשרטט Threat Model רשמי

רק תגיד:
➡️ “POC”, “Production” או “High‑Security”



הסבר כללי ופתרון מעשי 


להלן הפתרון המלא, המסודר והקריא, מהגדרת הבעיה → דרך תתי‑המערכות → ועד המלצה חד‑משמעית על
חלון הזמן ו‑סוג החתימה שיש להגדיר בראוטר.
אני כותב את זה כך שגם מהנדס שלא היה איתנו בשיחה יבין ויוכל ליישם.


1️⃣ הגדרת הבעיה (Problem Statement)

יש מערכת שבה:

  • ראוטרים/משדרים משדרים Wi‑Fi
  • טלפונים של נוסעים קולטים את השידור
  • בטלפון קיימת טבלת המרה ייעודית: מזהה משדר (MAC / ID) → מיקום פיזי (תחנה)

האיומים:

  1. תוקף משדר MAC זהה לראוטר חוקי (Cloning)
  2. תוקף משדר MAC של תחנה אחרת במיקום שגוי (Location Spoofing)
  3. תוקף מקליט שידור תקין ומשדר אותו מחדש (Replay)
  4. גם אם האפליקציה נפרצת –
    אסור שתיווצר יכולת לשדר תחנה מזויפת

2️⃣ עיקרון על (Principle)

לעולם לא סומכים על MAC / SSID בלבד
הם מזהים – לא זהות מאובטחת.

הפתרון חייב:

  • לזהות תחנה אמיתית
  • למנוע זיוף גם עם ציוד רגיל
  • להיות חסין גם כשאפליקציה נפרצת

3️⃣ הפתרון האידאלי (High‑Level Architecture)

הפתרון מבוסס על 4 שכבות אבטחה משלימות:

┌─────────────┐
│  Root Key   │   ← סודי, בתחנה בלבד
└─────┬───────┘
      ↓
┌─────────────┐
│ Session Key │   ← מתחלף בזמן
└─────┬───────┘
      ↓
┌─────────────┐
│ Signature   │   ← משודרת באוויר
└─────┬───────┘
      ↓
┌─────────────┐
│ App Verify  │   ← אימות + RSSI
└─────────────┘

4️⃣ תת‑מערכת 1: המפתחות (KEYs)

🔐 Root Key (לכל תחנה)

  • מפתח סודי ייחודי לכל תחנה
  • אורך: 256 ביט
  • נוצר אקראית בעת התקנה

מאפיינים:

  • ✅ לא משתנה
  • ✅ לא משודר
  • ✅ לא קיים באפליקציה
  • ✅ דליפה מאפליקציה ≠ סיכון

🔄 Session Key (מתחלף בזמן)

בכל תחנה:

SessionKey = HMAC(RootKey, TimeSlot)

מאפיינים:

  • משתנה כל הזמן
  • גם אם נחשף → תקף לזמן קצר
  • אי‑אפשר לגזור ממנו Root Key

5️⃣ תת‑מערכת 2: חלון הזמן (Time Slot)

❌ למה לא 10ms “אמיתי”?

  • Wi‑Fi לא דטרמיניסטי
  • טלפונים סובלים מדיליי Scheduler
  • גורם לפסילות שווא

✅ הפתרון הנכון: Time Slot קריפטוגרפי

הגדרה:

  • Crypto Time Slot:
    10ms (דרישתך – מתקיימת)

  • Broadcast Interval (השידור בפועל):
    100ms

חישוב:

CryptoSlot = floor(UnixTime / 10ms)

מה משודר:

  • לא 10 חתימות בשנייה
  • אלא חתימה אחת כל 100ms
  • שכוללת בתוכה את ה‑CryptoSlot

✅ חלון זמן מומלץ באפליקציה

האפליקציה תאמת:

CryptoSlot_now ± 3

כלומר:

  • חלון של ±30ms
  • מספיק לספוג:
    • סטיית שעון
    • דיליי קל
  • קטן מספיק כדי:
    • לחסום Replay

📌 זה האיזון האופטימלי


6️⃣ תת‑מערכת 3: החתימה (Signature)

✅ סוג חתימה מומלץ לראוטר

🔐 HMAC‑SHA256 ✅ (מומלץ)

למה:

  • מהיר
  • מוכח
  • נתמך בכל Embedded / Router
  • לא דורש ספריות כבדות

אופן החתימה:

Signature = HMAC(
   SessionKey,
   StationID + CryptoSlot
)

מה משודר באוויר:

StationID
CryptoSlot
Signature

❌ לא משודר:

  • Root Key
  • Session Key

למה לא חתימה אסימטרית?

  • כבד יותר
  • גדול יותר באוויר
  • לא נדרש לאיום שלך

HMAC הוא ה‑Sweet Spot.


7️⃣ תת‑מערכת 4: האפליקציה (טלפון הנוסע)

מה יש באפליקציה:

  • קוד אימות בלבד
  • לוגיקת זמן
  • RSSI

מה אין באפליקציה:

  • Root Key
  • Session Key
  • יכולת לחתום

📌 גם אם:

  • פורצים
  • מפרקים APK

❌ לא ניתן לשדר תחנה מזויפת


8️⃣ תת‑מערכת 5: RSSI (בדיקת היגיון פיזי)

RSSI משמש שכבת אבטחה משלימה:

האפליקציה בודקת:

  • רציפות עוצמה
  • קפיצות חשודות
  • הופעה/היעלמות חריגה

כלומר:

  • חתימה תקינה ✅
  • אבל RSSI לא הגיוני ❌
    → נפסל

זה חוסם:

  • Repeater
  • SDR מרוחק
  • Injection מרוחק

9️⃣ סיכום – למה זה הפתרון האידאלי

איוםנחסם
זיוף MAC
זיוף תחנה
Replay
פריצת אפליקציה
שידור מתחזה
עבודה בזמן אמת

📌 החלטות סופיות (One‑Page)

  • KEY לכל תחנה: Root Key ייחודי
  • KEY מתחלף: Session Key לפי Time Slot
  • Time Slot:
    • קריפטוגרפי: 10ms
    • שידור בפועל: 100ms
    • חלון אימות: ±3 slots
  • חתימה: HMAC‑SHA256
  • RSSI: סינון רציפות


הפוסטים הבולטים

GPS- פרמטרים באפלקציות מותאמות

  התמונה היא מאפליקציית GPSTest/GNSS Status , והיא מציגה את מצב קליטת ה-GNSS של הטלפון שלך. אעבור על כל הפרמטרים ומה הם אומרים על איכות הקלי...

פוסטים