❶ mmdvm注冊國內id還是國際id
可以注冊國際的也可以注冊國內的。
拓展：MMDVM注冊DMRid方法：
打開注冊地址，進入網站後，點擊注冊ID。
勾選「我同意上述條款和條件」，然後點擊注冊賬號。
在彈出的對話框中填寫呼號、郵箱、密碼等信息，人機身份驗證通過後點擊創建賬號。
填寫郵箱後會有「請檢查您的電子郵件，此窗口保持打開狀態。當您在電子郵件中看到「謝謝」消息後，請回到此處。」提示，此時打開你的郵箱確認郵件並進行下一步的注冊。
密碼設置必須滿足以下條件：至少一個小寫字母、至少一個大寫字母、至少一個號碼、至少一個符號、至少8個宇符
注冊成功後登陸賬號
登陸後進入儀表盤界面，修改個人信息，按照示例頁面上傳操作證書和電台執照。
❷ 數字dmr、p25、tetra等數字制式對講機能否互通D-star是否是數字制式還是數字信令
全部不能互通，都是不同的數字制式。
DMR是目前我國正在逐漸流行的 數字制式，很多國產廠家HYT\北峰、科利訊都有對應型號。
P25是美軍軍標標准，P25制式的機器一般是走私進入我國，美國政府不允許P25制式的通訊設備出口我國。
TETRA是另一種數字模式，不同於DMR的大區制，更傾向於手機的風格。
D-star是ICOM創立的比較老的數字模式，目前看趨勢有被淘汰的危險。
❸ 誰能介紹下oracle資料庫的前滾rolling forward原理嗎
偶然的一次，網友在t.askmaclean.com ASK Maclean Home提問了關於11.2 上一個ORA-600問題的解決途徑，我們這里不討論該ORA-600[kcratr_nab_less_than_odr]錯誤， 比這個錯誤本身更有趣的是 該600 trace中記錄了一段對於前滾恢復rolling upgrade描述十分詳細的KST trace。
很多網友肯定要問什麼是KST? KST是9i以後引入的內部診斷機制Tracing Facility，每一個Oracle 進程都維護SGA中的一小塊Trace buffer，並將自身的默認啟用的一些event事件信息寫入到Trace Buffer中(這些事件默認包括10280, 10401, 10441, 10442, 10425, 10427, 10429, 10434, 10666)，可以使用內部視圖x$trace觀察這些信息，默認Trace Buffer不寫到磁碟上，而只在SGA中維護，當Trace Buffer用完時將被重用。
了解了 KST的知識後，我們可以從容地閱讀下面這段TRACE了：
Trace Bucket Dump Begin: default bucket for process 19 (osid: 29785)
TIME(*=approx):SEQ:COMPONENT:FILE@LINE:FUNCTION:SECT/DUMP: [EVENT#:PID:SID] DATA
以上是KST Trace的 頭部
COMPONENT 組件名 例如 db_trace 、CACHE_RCV，這里的CACHE_RCV意為 cache recovery，實際上是我們所說的前滾rolling forward。
FILE@LINE 指oracle內核代碼的文件名和行數 例如:kst.c、kcv.c，這些都是oracle的核心C代碼名
FUNCTION 指oracle內核函數名 例如kcvcrv()、kctrec()
[EVENT#:PID:SID] 即 EVENT ID:PID:SID
DATA 實際的操作內容
我們選擇性地閱讀KST TRACE的內容：
2012-02-07 13:40:52.755567 :800005B3:CACHE_RCV:kcv.c@15475:kcvcrv(): kcvcrv: Entering kcvcrv()2012-02-07 13:40:52.755609 :800005B4:KFNU:kfn.c@2200:kfnPrepareASM(): kfnPrepareASM force=0 state_kfnsg=0x7
2012-02-07 13:40:52.772999*:800005B5:CACHE_RCV:kcv.c@16100:kcvcrv(): kcvcrv: file 1 - cpscn 0x0000.018b76b2, rsflg 0
2012-02-07 13:40:52.826001*:800005B6:CACHE_RCV:kcv.c@16100:kcvcrv(): kcvcrv: file 2 - cpscn 0x0000.018b76b2, rsflg 0
2012-02-07 13:40:52.862014*:800005B7:CACHE_RCV:kcv.c@16100:kcvcrv(): kcvcrv: file 3 - cpscn 0x0000.018b76b2, rsflg 0
2012-02-07 13:40:52.909981*:800005B8:CACHE_RCV:kcv.c@16100:kcvcrv(): kcvcrv: file 4 - cpscn 0x0000.018b76b2, rsflg 0
2012-02-07 13:40:52.945933*:800005B9:CACHE_RCV:kcv.c@16100:kcvcrv(): kcvcrv: file 5 - cpscn 0x0000.018b76b2, rsflg 0
2012-02-07 13:40:52.993824*:800005BA:CACHE_RCV:kcv.c@16100:kcvcrv(): kcvcrv: file 6 - cpscn 0x0000.018b76b2, rsflg 0
2012-02-07 13:40:53.005829*:800005BB:CACHE_RCV:kcv.c@16100:kcvcrv(): kcvcrv: file 7 - cpscn 0x0000.018b76b2, rsflg 0
2012-02-07 13:40:53.041893*:800005BC:CACHE_RCV:kcv.c@16100:kcvcrv(): kcvcrv: file 8 - cpscn 0x0000.018b76b2, rsflg 0
2012-02-07 13:40:53.065779*:800005BD:CACHE_RCV:kcv.c@16100:kcvcrv(): kcvcrv: file 9 - cpscn 0x0000.018b76b2, rsflg 0
2012-02-07 13:40:53.089760*:800005BE:CACHE_RCV:kcv.c@16100:kcvcrv(): kcvcrv: file 10 - cpscn 0x0000.018b76b2, rsflg 0
kcvcrv的全稱是 [K]ernel [C]ache [R]ecovery [C]rash [R]ecovery [V]erify ， kcvcrv內核函數在crash recovery的過程中顯得極為重要，它總是發生在當一個前台進程試圖啟動臟關閉(dirty shutdown)的資料庫的時候。kcvcrv 的工作包括檢驗所有的數據文件頭並驗證控制文件中的數據文件記錄以確認是否需要介質恢復。這個步驟必要地驗證僅僅crash recovery是否足以讓資料庫恢復到一致狀態(consistent)，相信大家已經耳熟能詳 crash recovery 、 instance recovery 、 media recovery 三者的區別。 若kcvcrv發現 data files數據文件、control files控制文件亦或者redo log file在線日誌文件存在corrupted 或者 丟失，或者實際上是從之前的備份中還原過來的，那麼kcvcrv會強制用戶必須使用media recovery才能將資料庫恢復到一致，無法通過crash recovery實現恢復。注意 kcvcrv的檢測並不是完全的，它主要是檢測 數據文件頭的checkpoint scn 和 控制文件中data files的checkpoint scn是否一致，以確保 這些數據文件完成了shutdown instance時的最後一次FULL Checkpoint。 kcvcrv並不能檢測出除數據文件頭部外的datafile body是否存在介質訛誤。
kcvcrv需要對control file讀寫才能完成其必要的任務，所以它會啟動一個控制文件讀寫事務 read-write control file transaction。通過檢驗控制文件中每個數據文件的記錄以確認數據文件是否有被重新同步的必要。 當然kcvcrv會跳過哪些OFFLINE和read-only的數據文件，因為這些文件不存在recovery的必要。
在確認crash recovery的必要性後，kcvcrv還會主導啟動並行的恢復工作(parallel recovery)，注意parallel recovery只在多CPU且參數recovery_parallelism不為零的環境下有效， kcvcrv會創建並初始化Oracle中的PQ Slave 並行子進程以便恢復實例。 默認的子進程數Slave Processes等於(CPU的總數-1)，這是因為需要為recovery coordinator process恢復協調進程保留一個CPU。並且需要kcvcrv分配一個recovery state object給並行恢復 協調進程與其Slave子進程。
最後kcvcrv還會調用另一個關鍵內核函數 kctrec ( Kernel Cache Threads )， kctrec會在所有打開的redo thread上實施進一步的thread recovery。
2012-02-07 13:40:53.366569 :80000687:KFNU:kfn.c@2200:kfnPrepareASM(): kfnPrepareASM force=0 state_kfnsg=0x7
2012-02-07 13:40:53.366569*:80000688:CACHE_RCV:kcv.c@16365:kcvcrv(): kcvcrv: Calling kctrec()
2012-02-07 13:40:53.366569*:80000689:CACHE_RCV:kct.c@4163:kctrec(): kctrec: Entering kctrec()
2012-02-07 13:40:53.413557*:8000068A:CACHE_RCV:kct.c@4271:kctrec(): kctrec: thread 1 cf thread ckpt: logseq 1468, block 2,scn 25917106
常見的 kcvcrv 調用堆棧 stack call如下：
kcratr_odr_check <- kcratr <- kctrec <- kcvcrv <- kcfopd <- adbdrv
kcliarq <- kclrinit <- kcbrst <- kcrpci <- kcratr <- kctrec <- kcvcrv <- kcfopd <- adbdrv
kfgrpIterInit()<-kfis_sageonly_anygroup()<-krr_init_rrx()<-kcra_scan_redo()<-kcra_mp_redo()+2246<-kcra_mp_redo_internal()+1752<-kco_image_corrupt()<-kcoapl()<-kcbr_apply_change()<-kcbr_mapply_change()<-kcbrapply()<-kcbr_apply_pending()<-kcbr_media_apply()<-krp_serial_apply()<-krr_do_media_recovery()<-krddmr()<-krd_do_media_rcv()<-krd_implicit_rcv()<-kcvcrv()<-kcfopd()<-adbdrv()